@git / git-reference
Code Commits Issues Pulls Cloud Agent CI/CD
clearly-describe-rm-mv
clearly-describe-rm-mv gh-pages
html 973 lines 33.7 KB
Raw
1 ---
2 layout: reference
3 ---
4
5 <div class="box">
6 <h2>
7 <span class="docs">
8 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository">book</a>
9 </span>
10 Basic Snapshotting
11 </h2>
12 <div class="block">
13 <p>
14 Git is all about composing and saving snapshots of your project and then
15 working with and comparing those snapshots. This section will explain
16 the commands needed to compose and commit snapshots of your project.
17 </p>
18
19 <p>
20 An important concept here is that Git has an 'index', which acts as sort
21 of a staging area for your snapshot. This allows you to build up a series
22 of well composed snapshots from changed files in your working directory,
23 rather than having to commit all of the file changes at once.
24 </p>
25
26 <p class="nutshell">
27 <strong>In a nutshell</strong>, you will use <code>git add</code> to start tracking new
28 files and also to stage changes to already tracked files, then
29 <code>git status</code> and <code>git diff</code> to see what has been
30 modified and staged and finally <code>git commit</code> to record your
31 snapshot into your history. This will be the basic workflow that you use
32 most of the time.
33 </p>
34
35 </div>
36 </div>
37
38 <div class="box">
39 <h2>
40 <span class="docs">
41 <a target="new" href="http://git-scm.com/docs/git-add">docs</a> &nbsp;
42 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Tracking-New-Files">book</a>
43 </span>
44 <a name="add">git add</a>
45 <span class="desc">adds file contents to the staging area</span>
46 </h2>
47
48 <div class="block">
49 <p>
50 In Git, you have to add file contents to your staging area before you
51 can commit them. If the file is new, you can run <code>git add</code>
52 to initially add the file to your staging area, but even if the file
53 is already "tracked" - ie, it was in your last commit - you still need
54 to call <code>git add</code> to add new modifications to your staging
55 area. Let's see a few examples of this.
56 </p>
57
58 <p>Going back to our Hello World example, once we've initiated the project,
59 we would now start adding our files to it and we would do that with
60 <code>git add</code>. We can use <code>git status</code> to see what the
61 state of our project is.
62 </p>
63
64 <pre>
65 <b>$ git status -s</b>
66 <span class="red">??</span> README
67 <span class="red">??</span> hello.rb
68 </pre>
69
70 So right now we have two untracked files. We can now add them.
71
72 <pre>
73 <b>$ git add README hello.rb</b>
74 </pre>
75
76 Now if we run <code>git status</code> again, we'll see that they've been
77 added.
78
79 <pre>
80 <b>$ git status -s</b>
81 <span class="green">A</span> README
82 <span class="green">A</span> hello.rb
83 </pre>
84
85 <p class="aside">
86 It is also common to recursively add all files in a new project by specifying
87 the current working directory like this: <code>git add .</code>. Since Git
88 will recursively add all files under a directory you give it, if you give it
89 the current working directory, it will simply start tracking every file
90 there. In this case, a <code>git add .</code> would have done the same
91 thing as a <code>git add README hello.rb</code>, or for that matter so would
92 <code>git add *</code>, but that's only because we don't have subdirectories
93 which the <code>*</code> would not recurse into.
94 </p>
95
96 <p>OK, so now if we edit one of these files and run <code>git status</code>
97 again, we will see something odd.</p>
98 <pre>
99 <b>$ vim README</b>
100 <b>$ git status -s</b>
101 <span class="green">A</span><span class="red">M</span> README
102 <span class="green">A</span> hello.rb
103 </pre>
104
105 <p>The 'AM' status means that the file has been modified on disk since we
106 last added it. This means that if we commit our snapshot right now, we will
107 be recording the version of the file when we last ran <code>git add</code>,
108 not the version that is on our disk. Git does not assume that what the file
109 looks like on disk is necessarily what you want to snapshot - you have to
110 tell Git with the <code>git add</code> command.
111 </p>
112
113 <p class="nutshell">
114 <strong>In a nutshell</strong>,
115 you run <code>git add</code> on a file when you want to
116 include whatever changes you've made to it in your next commit snapshot.
117 Anything you've changed that is not added will not be included - this means
118 you can craft your snapshots with a bit more precision than most other SCM
119 systems.</p>
120
121 <p>For a very interesting example of using this flexibility to stage only
122 parts of modified files at a time, see the '-p' option to
123 <code>git add</code> in the Pro Git book.</p>
124
125
126 </div>
127
128 </div>
129
130 <div class="box">
131 <h2>
132 <span class="docs">
133 <a target="new" href="http://git-scm.com/docs/git-status">docs</a> &nbsp;
134 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Checking-the-Status-of-Your-Files">book</a>
135 </span>
136 <a name="status">git status</a>
137 <span class="desc">view the status of your files in the working directory and staging area</span>
138 </h2>
139
140 <div class="block">
141 <p>As you saw in the <code>git add</code> section, in order to see what the
142 status of your staging area is compared to the code in your working
143 directory, you can run the <code>git status</code> command. Using the
144 <code>-s</code> option will give you short output.
145 Without that flag, the <code>git status</code> command will give you more
146 context and hints. Here is the same status output with and without the
147 <code>-s</code>. The short output looks like this:
148 </p>
149
150 <pre>
151 <b>$ git status -s</b>
152 <span class="green">A</span><span class="red">M</span> README
153 <span class="green">A</span> hello.rb
154 </pre>
155
156 Where the same status with the long output looks like this:
157
158 <pre>
159 <b>$ git status</b>
160 # On branch master
161 #
162 # Initial commit
163 #
164 # Changes to be committed:
165 # (use "git rm --cached &lt;file>..." to unstage)
166 #
167 # <span class="green">new file: README</span>
168 # <span class="green">new file: hello.rb</span>
169 #
170 # Changed but not updated:
171 # (use "git add &lt;file>..." to update what will be committed)
172 # (use "git checkout -- &lt;file>..." to discard changes in working directory)
173 #
174 # <span class="red">modified: README</span>
175 #
176 </pre>
177
178 <p>You can easily see how much more compact the short output is, but the
179 long output has useful tips and hints as to what commands you may want to
180 use next.
181 </p>
182
183 <p>Git will also tell you about files that were deleted since your last
184 commit or files that were modified or staged since your last commit.</p>
185
186 <pre>
187 <b>$ git status -s</b>
188 <span class="green">M</span> README
189 <span class="red">D</span> hello.rb
190 </pre>
191
192 You can see there are two columns in the short status output. The first
193 column is for the staging area, the second is for the working directory.
194 So for example, if you have the README file staged and then you modify
195 it again without running <code>git add</code> a second time, you'll see
196 this:
197
198 <pre>
199 <b>$ git status -s</b>
200 <span class="green">M</span><span class="red">M</span> README
201 <span class="red">D</span> hello.rb
202 </pre>
203
204 <p class="nutshell">
205 <strong>In a nutshell</strong>,
206 you run <code>git status</code> to see if anything has been modified
207 and/or staged since your last commit so you can decide if you want to
208 commit a new snapshot and what will be recorded in it.
209 </p>
210
211 </div>
212 </div>
213
214 <div class="box">
215 <h2>
216 <span class="docs">
217 <a target="new" href="http://git-scm.com/docs/git-diff">docs</a> &nbsp;
218 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Viewing-Your-Staged-and-Unstaged-Changes">book</a>
219 </span>
220 <a name="diff">git diff</a>
221 <span class="desc">shows diff of what is staged and what is modified but unstaged</span>
222 </h2>
223
224 <div class="block">
225 <p>There are two main uses of the <code>git diff</code> command. One use we
226 will describe here, the other we will describe later in the
227 <a href="/inspect">"Inspection and Comparison"</a>
228 section. The way we're going to use it here is to describe the
229 changes that are staged or modified on disk but unstaged.</p>
230
231 <h4>
232 git diff
233 <small>show diff of unstaged changes</small>
234 </h4>
235
236 <p>Without any extra arguments, a simple <code>git diff</code> will display
237 in unified diff format (a patch) what code or content you've changed in your
238 project since the last commit that are not yet staged for the next commit
239 snapshot.
240 </p>
241
242 <pre>
243 <b>$ vim hello.rb</b>
244 <b>$ git status -s</b>
245 <span class="red">M</span> hello.rb
246 <b>$ git diff</b>
247 <span class="umber">diff --git a/hello.rb b/hello.rb
248 index d62ac43..8d15d50 100644
249 --- a/hello.rb
250 +++ b/hello.rb</span>
251 <span class="lblue">@@ -1,7 +1,7 @@</span>
252 class HelloWorld
253
254 def self.hello
255 <span class="red">- puts "hello world"</span>
256 <span class="green">+ puts "hola mundo"</span>
257 end
258
259 end
260 </pre>
261
262 <p>So where <code>git status</code> will show you what files have changed
263 and/or been staged since your last commit, <code>git diff</code> will
264 show you what those changes actually are, line by line. It's generally
265 a good follow-up command to <code>git status</code>
266 </p>
267
268 <h4 id="diff-cached">
269 git diff --cached
270 <small>show diff of staged changes</small>
271 </h4>
272
273 <p>The <code>git diff --cached</code> command will show you what contents
274 have been staged. That is, this will show you the changes that will
275 currently go into the next commit snapshot. So, if you were to stage
276 the change to <code>hello.rb</code> in the example above,
277 <code>git diff</code> by itself won't show you any output because it will
278 only show you what is <i>not yet</i> staged.
279 </p>
280
281 <pre>
282 <b>$ git status -s</b>
283 <span class="red">M</span> hello.rb
284 <b>$ git add hello.rb </b>
285 <b>$ git status -s</b>
286 <span class="green">M</span> hello.rb
287 <b>$ git diff</b>
288 <b>$ </b>
289 </pre>
290
291 <p>If you want to see the staged changes, you can run
292 <code>git diff --cached</code> instead.</p>
293
294 <pre>
295 <b>$ git status -s</b>
296 <span class="green">M</span> hello.rb
297 <b>$ git diff</b>
298 <b>$ </b>
299 <b>$ git diff --cached</b>
300 <span class="umber">diff --git a/hello.rb b/hello.rb
301 index d62ac43..8d15d50 100644
302 --- a/hello.rb
303 +++ b/hello.rb</span>
304 <span class="lblue">@@ -1,7 +1,7 @@</span>
305 class HelloWorld
306
307 def self.hello
308 <span class="red">- puts "hello world"</span>
309 <span class="green">+ puts "hola mundo"</span>
310 end
311
312 end
313 </pre>
314
315 <h4 id="diff-head">
316 git diff HEAD
317 <small>show diff of all staged or unstaged changes</small>
318 </h4>
319
320 <p>If you want to see both staged and unstaged changes together, you
321 can run <code>git diff HEAD</code> - this basically means you want to
322 see the difference between your working directory and the last commit,
323 ignoring the staging area. If we make another change to our
324 <code>hello.rb</code> file then we'll have some changes staged and some
325 changes unstaged. Here are what all three <code>diff</code> commands
326 will show you:</p>
327 <pre>
328 <b>$ vim hello.rb </b>
329 <b>$ git diff</b>
330 <span class="umber">diff --git a/hello.rb b/hello.rb
331 index 4f40006..2ae9ba4 100644
332 --- a/hello.rb
333 +++ b/hello.rb</span>
334 <span class="lblue">@@ -1,7 +1,7 @@</span>
335 class HelloWorld
336
337 <span class="green">+ # says hello</span>
338 def self.hello
339 puts "hola mundo"
340 end
341
342 end
343 <b>$ git diff --cached</b>
344 <span class="umber">diff --git a/hello.rb b/hello.rb
345 index 2aabb6e..4f40006 100644
346 --- a/hello.rb
347 +++ b/hello.rb</span>
348 <span class="lblue">@@ -1,7 +1,7 @@</span>
349 class HelloWorld
350
351 def self.hello
352 <span class="red">- puts "hello world"</span>
353 <span class="green">+ puts "hola mundo"</span>
354 end
355
356 end
357 <b>$ git diff HEAD</b>
358 <span class="umber">diff --git a/hello.rb b/hello.rb
359 index 2aabb6e..2ae9ba4 100644
360 --- a/hello.rb
361 +++ b/hello.rb</span>
362 <span class="lblue">@@ -1,7 +1,8 @@</span>
363 class HelloWorld
364
365 <span class="green">+ # says hello</span>
366 def self.hello
367 <span class="red">- puts "hello world"</span>
368 <span class="green">+ puts "hola mundo"</span>
369 end
370
371 end
372 </pre>
373
374 <h4 id="diff-stat">
375 git diff --stat
376 <small>show summary of changes instead of a full diff</small>
377 </h4>
378
379 <p>If we don't want the full diff output, but we want more than the
380 <code>git status</code> output, we can use the <code>--stat</code>
381 option, which will give us a summary of changes instead. Here is the
382 same example as above, but using the <code>--stat</code> option instead.
383 </p>
384
385 <pre>
386 <b>$ git status -s</b>
387 <span class="green">M</span><span class="red">M</span> hello.rb
388 <b>$ git diff --stat</b>
389 hello.rb | 1 <span class="green">+</span>
390 1 files changed, 1 insertions(+), 0 deletions(-)
391 <b>$ git diff --cached --stat</b>
392 hello.rb | 2 <span class="green">+</span><span class="red">-</span>
393 1 files changed, 1 insertions(+), 1 deletions(-)
394 <b>$ git diff HEAD --stat</b>
395 hello.rb | 3 <span class="green">++</span><span class="red">-</span>
396 1 files changed, 2 insertions(+), 1 deletions(-)
397 </pre>
398
399 <p>
400 You can also provide a file path at the end of any of these options
401 to limit the <code>diff</code> output to a specific file or subdirectory.
402 </p>
403
404
405 <p class="nutshell">
406 <strong>In a nutshell</strong>,
407 you run <code>git diff</code> to see details of the <code>git status</code>
408 command - <i>how</i> files have been modified or staged on a line by line
409 basis.
410 </p>
411
412
413 </div>
414 </div>
415
416 <div class="box">
417 <h2>
418 <span class="docs">
419 <a target="new" href="http://git-scm.com/docs/git-commit">docs</a> &nbsp;
420 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Committing-Your-Changes">book</a>
421 </span>
422 <a name="commit">git commit</a>
423 <span class="desc">records a snapshot of the staging area</span>
424 </h2>
425
426 <div class="block">
427
428 <p>Now that you have staged the content you want to snapshot with the
429 <code>git add</code> command, you run <code>git commit</code> to actually
430 record the snapshot.
431 Git records your name and email address with every commit you make,
432 so the first step is to tell Git what these are.
433 </p>
434
435 <pre>
436 <b>$ git config --global user.name 'Your Name'</b>
437 <b>$ git config --global user.email you@somedomain.com</b>
438 </pre>
439
440 <p>Let's stage and commit all the changes to our
441 <code>hello.rb</code> file. In this first example, we'll use the
442 <code>-m</code> option to provide the commit message on the command line.
443 </p>
444
445 <pre>
446 <b>$ git add hello.rb </b>
447 <b>$ git status -s</b>
448 <span class="green">M</span> hello.rb
449 <b>$ git commit -m 'my hola mundo changes'</b>
450 [master 68aa034] my hola mundo changes
451 1 files changed, 2 insertions(+), 1 deletions(-)
452 </pre>
453
454 <p>Now we have recorded the snapshot. If we run <code>git status</code>
455 again, we will see that we have a "clean working directory", which means
456 that we have not made any changes since our last commit - there is no
457 un-snapshotted work in our checkout.</p>
458
459 <pre>
460 <b>$ git status</b>
461 # On branch master
462 nothing to commit (working directory clean)
463 </pre>
464
465 <p>If you leave off the <code>-m</code> option, Git will try to open a
466 text editor for you to write your commit message. In <code>vim</code>,
467 which it will default to if it can find nothing else in your settings,
468 the screen might look something like this:
469 </p>
470
471 <pre>
472
473 # Please enter the commit message for your changes. Lines starting
474 # with '#' will be ignored, and an empty message aborts the commit.
475 # On branch master
476 # Changes to be committed:
477 # (use "git reset HEAD &lt;file>..." to unstage)
478 #
479 # modified: hello.rb
480 #
481 ~
482 ~
483 ".git/COMMIT_EDITMSG" 9L, 257C
484 </pre>
485
486 <p>At this point you add your actual commit message at the top of the
487 document. Any lines starting with '#' will be ignored - Git will put
488 the output of the <code>git status</code> command in there for you as
489 a reminder of what you have modified and staged.</p>
490
491 <p>In general, it's very important to write a good commit message.
492 For open source projects, it's generally a rule to write your message
493 more or less in this format:</p>
494
495 <pre>
496 Short (50 chars or less) summary of changes
497
498 More detailed explanatory text, if necessary. Wrap it to about 72
499 characters or so. In some contexts, the first line is treated as the
500 subject of an email and the rest of the text as the body. The blank
501 line separating the summary from the body is critical (unless you omit
502 the body entirely); some git tools can get confused if you run the
503 two together.
504
505 Further paragraphs come after blank lines.
506
507 - Bullet points are okay, too
508
509 - Typically a hyphen or asterisk is used for the bullet, preceded by a
510 single space, with blank lines in between, but conventions vary
511 here
512
513 # Please enter the commit message for your changes. Lines starting
514 # with '#' will be ignored, and an empty message aborts the commit.
515 # On branch master
516 # Changes to be committed:
517 # (use "git reset HEAD &lt;file>..." to unstage)
518 #
519 # modified: hello.rb
520 #
521 ~
522 ~
523 ~
524 ".git/COMMIT_EDITMSG" 25L, 884C written
525 </pre>
526
527 <p class="aside">
528 The commit message is very important. Since much of the power of
529 Git is this flexibility in carefully crafting commits locally and then
530 sharing them later, it is very powerful to be able to write three or
531 four commits of logically separate changes so that your work may be more
532 easily peer reviewed. Since there is a separation between committing and
533 pushing those changes, do take the time to make it easier for the people
534 you are working with to see what you've done by putting each logically
535 separate change in a separate commit with a nice commit message so it
536 is easier for them to see what you are doing and why.</p>
537
538 <h4 id="commit-a">
539 git commit -a
540 <small>automatically stage all tracked, modified files before the commit</small>
541 </h4>
542
543 <p>If you think the <code>git add</code> stage of the workflow is too
544 cumbersome, Git allows you to skip that part with the <code>-a</code>
545 option. This basically tells Git to run <code>git add</code> on any file
546 that is "tracked" - that is, any file that was in your last commit and
547 has been modified. This allows you to do a more Subversion style workflow
548 if you want, simply editing files and then running <code>git commit -a</code>
549 when you want to snapshot everything that has been changed. You still need
550 to run <code>git add</code> to start tracking new files, though, just like
551 Subversion.
552 </p>
553
554 <pre>
555 <b>$ vim hello.rb</b>
556 <b>$ git status -s</b>
557 <span class="red">M</span> hello.rb
558 <b>$ git commit -m 'changes to hello file'</b>
559 # On branch master
560 # Changed but not updated:
561 # (use "git add &lt;file>..." to update what will be committed)
562 # (use "git checkout -- &lt;file>..." to discard changes in working directory)
563 #
564 # modified: hello.rb
565 #
566 <span class="hl">no changes added to commit (use "git add" and/or "git commit -a")</span>
567 <b>$ git commit -am 'changes to hello file'</b>
568 [master 78b2670] changes to hello file
569 1 files changed, 2 insertions(+), 1 deletions(-)
570 </pre>
571
572 <p>Notice how if you don't stage any changes and then run
573 <code>git commit</code>, Git will simply give you the output of the
574 <code>git status</code> command, reminding you that nothing is staged.
575 The important part of that message has been highlighted, saying that nothing
576 is added to be committed. If you use <code>-a</code>, it will add and
577 commit everything at once.
578 </p>
579
580 <p>This now lets you complete the entire snapshotting workflow - you
581 make changes to your files, then use <code>git add</code> to stage
582 files you want to change, <code>git status</code> and <code>git diff</code>
583 to see what you've changed, and then finally <code>git commit</code>
584 to actually record the snapshot forever.</p>
585
586 <p class="nutshell">
587 <strong>In a nutshell</strong>,
588 you run <code>git commit</code> to record the snapshot of your staged
589 content. This snapshot can then be compared, shared and reverted to
590 if you need to.
591 </p>
592
593 </div>
594 </div>
595
596 <div class="box">
597 <h2>
598 <span class="docs">
599 <a target="new" href="http://git-scm.com/docs/git-reset">docs</a> &nbsp;
600 <a target="new" href="http://git-scm.com/book/en/Git-Basics-Undoing-Things#Unstaging-a-Staged-File">book</a>
601 </span>
602 <a name="reset">git reset</a>
603 <span class="desc">undo changes and commits</span>
604 </h2>
605
606 <div class="block">
607 <p><code>git reset</code> is probably the most confusing command written
608 by humans, but it can be very useful once you get the hang of it.
609 There are three specific invocations of it that are generally
610 helpful.
611 </p>
612
613 <h4 id="reset-head">
614 git reset HEAD
615 <small>unstage files from index and reset pointer to HEAD</small>
616 </h4>
617
618 <p>First, you can use it to unstage something that has been
619 accidentally staged. Let's say that you have modified two files and want
620 to record them into two different commits. You should stage and commit
621 one, then stage and commit the other. If you accidentally stage both of
622 them, how do you <i>un-</i>stage one? You do it with
623 <code>git reset HEAD -- file</code>. Technically you don't have to
624 add the <code>--</code> - it is used to tell Git when you have stopped
625 listing options and are now listing file paths, but it's probably good to
626 get into the habit of using it to separate options from paths even if you
627 don't need to.
628 </p>
629
630 <p>Let's see what it looks like to unstage something. Here we have
631 two files that have been modified since our last commit. We will stage
632 both, then unstage one of them.</p>
633
634 <pre>
635 <b>$ git status -s</b>
636 <span class="red">M</span> README
637 <span class="red">M</span> hello.rb
638 <b>$ git add .</b>
639 <b>$ git status -s</b>
640 <span class="green">M</span> README
641 <span class="green">M</span> hello.rb
642 <b>$ git reset HEAD -- hello.rb </b>
643 Unstaged changes after reset:
644 M hello.rb
645 <b>$ git status -s</b>
646 <span class="green">M</span> README
647 <span class="red">M</span> hello.rb
648 </pre>
649
650 <p>Now you can run a <code>git commit</code> which will just record
651 the changes to the <code>README</code> file, not the now unstaged
652 <code>hello.rb</code>.
653 </p>
654
655 <p class="aside">
656 In case you're curious, what it's actually doing here is it is resetting
657 the checksum of the entry for that file in the "index" to be what it was
658 in the last commit. Since <code>git add</code> checksums a file and adds
659 it to the "index", <code>git reset HEAD</code> overwrites that with what
660 it was before, thereby effectively unstaging it.
661 </p>
662
663 <p class="tip">
664 If you want to be able to just run <code>git unstage</code>, you can easily
665 setup an alias in Git. Just run
666 <code>git config --global alias.unstage "reset HEAD"</code>.
667 Once you have run that, you can then just run
668 <code>git unstage [file]</code> instead.
669 </p>
670
671 <p>If you forget the command to unstage something, Git is helpful in
672 reminding you in the output of the normal <code>git status</code>
673 command. For example, if you run <code>git status</code> without
674 the <code>-s</code> when you have staged files, it will tell you
675 how to unstage them:</p>
676
677 <pre>
678 <b>$ git status</b>
679 # On branch master
680 # Changes to be committed:
681 # <span class="hl">(use "git reset HEAD &lt;file>..." to unstage)</span>
682 #
683 # <span class="green">modified: README</span>
684 # <span class="green">modified: hello.rb</span>
685 #
686 </pre>
687
688 <p>When you run <code>git reset</code> without specifying a flag
689 it defaults to <code>--mixed</code>. The other options are
690 <code>--soft</code> and <code>--hard</code>.</p>
691
692 <h4 id="reset-soft">
693 git reset --soft
694 <small>moves HEAD to specified commit reference, index and staging are untouched</small>
695 </h4>
696
697 <p>The first thing <code>git reset</code> does is undo the last
698 commit and put the files back onto the stage. If you include the
699 <code>--soft</code> flag this is where it stops. For example,
700 if you run <code>git reset --soft HEAD~</code> (the parent of the
701 HEAD) the last commit will be undone and the files touched
702 will be back on the stage again.</p>
703
704 <pre>
705 <b>$ git status -s</b>
706 <span class="green">M</span> hello.rb
707 <b>$ git commit -am 'hello with a flower'</b>
708 [master 5857ac1] hello with a flower
709 1 files changed, 3 insertions(+), 1 deletions(-)
710 <b>$ git status</b>
711 # On branch master
712 nothing to commit (working directory clean)
713 <b>$ git reset --soft HEAD~</b>
714 <b>$ git status -s</b>
715 <span class="green">M</span> hello.rb
716 </pre>
717
718 <p>This is basically doing the same thing as
719 <code>git commit --amend</code>, allowing you to do more work
720 before you roll in the file changes into the same commit.</p>
721
722 <h4 id="reset-hard">
723 git reset --hard
724 <small>unstage files AND undo any changes in the working directory since last commit</small>
725 </h4>
726
727 <p>The third option is to go <code>--hard</code>. This command discards your staged changes and
728 the changes in your working directory. In other words: it resets your staging area and working
729 directory to the state they were in at the given commit. This is the most
730 dangerous option and is not working directory safe. Any changes not committed will
731 be lost.
732 </p>
733
734 <pre>
735 <b>$ git status</b>
736 # On branch master
737 # Changes to be committed:
738 # (use "git reset HEAD &lt;file>..." to unstage)
739 #
740 # <span class="green">modified: README</span>
741 #
742 # Changes not staged for commit:
743 # (use "git add &lt;file>..." to update what will be committed)
744 # (use "git checkout -- &lt;file>..." to discard changes in working directory)
745 #
746 # <span class="red">modified: README</span>
747 #
748 <b>$ git reset --hard HEAD</b>
749 HEAD is now at 5857ac1 hello with a flower
750 <b>$ git status</b>
751 # On branch master
752 nothing to commit (working directory clean)
753 </pre>
754
755 <p>In the above example, while we had both changes ready to commit and
756 ready to stage, a <code>git reset --hard</code> wiped them out.
757 The working tree and staging area are reset to the tip of the current
758 branch or HEAD.</p>
759
760 <p>You can replace <code>HEAD</code> with a commit SHA-1 or another
761 parent reference to reset to that specific point.</p>
762
763 <p class="nutshell">
764 <strong>In a nutshell</strong>,
765 you run <code>git reset HEAD</code> to undo the last commit, unstage
766 files that you previously ran <code>git add</code> on and wish to not
767 include in the next commit snapshot</p>
768
769 </div>
770 </div>
771
772 <div class="box">
773 <h2>
774 <span class="docs">
775 <a href="http://git-scm.com/docs/git-rm">docs</a> &nbsp;
776 <a href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Removing-Files">book</a>
777 </span>
778 <a name="rm-mv">git rm</a>
779 <span class="desc">remove files from the staging area</span>
780 </h2>
781
782 <div class="block">
783
784 <p><code>git rm</code> will remove entries from the staging area.
785 This is a bit different from <code>git reset HEAD</code> which "unstages"
786 files. To "unstage" means it reverts the staging area to what was
787 there before we started modifying things. <code>git rm</code> on the
788 other hand just kicks the file off the stage entirely, so that it's not
789 included in the next commit snapshot, thereby effectively deleting it.</p>
790
791 <p>By default, a <code>git rm file</code> will remove the file from the
792 staging area entirely and also off your disk (the working directory). To
793 leave the file in the working directory, you can use <code>git rm --cached
794 </code>.</p>
795
796 <p class="aside">
797 In its normal form the command is used to delete files.
798 But it's often easier to just remove the files off your disk and
799 then run <code>git commit -a</code>, which will also automatically remove
800 them from your index.</p>
801
802 <h4>
803 git mv
804 <small>git rm --cached orig; mv orig new; git add new</small>
805 </h4>
806
807 <p>
808 Unlike most other version control systems, Git does not track file renames.
809 Instead, it just tracks the snapshots and then figures out what files were
810 likely renamed by comparing snapshots. If a file was removed from one
811 snapshot and another file was added to the next one and the contents are
812 similar, Git figures it was most likely a rename. So, although the
813 <code>git mv</code> command exists, it is superfluous - all it does is a
814 <code>git rm --cached</code>, moves the file on disk, then runs a
815 <code>git add</code> on the new file. You don't really need to use it, but
816 if it's easier, feel free.
817 </p>
818
819 <p class="nutshell">
820 <strong>In a nutshell</strong>,
821 you run <code>git rm</code> to remove files from being tracked in Git. It
822 will also remove them from your working directory. If you run <code> git mv</code> it will do essentially the same as <code>git rm --cached</code>, move the file on disk and run <code>git add</code> on the new file.
823 </p>
824
825 </div>
826 </div>
827
828 <div class="box">
829 <h2>
830 <span class="docs">
831 <a href="http://git-scm.com/docs/git-stash">docs</a> &nbsp;
832 <a href="http://git-scm.com/book/en/Git-Tools-Stashing">book</a>
833 </span>
834 <a name="stash">git stash</a>
835 <span class="desc">save changes made in the current index and working directory for later</span>
836 </h2>
837
838 <div class="block">
839
840 <p>You're in the middle of some changes but something comes up that you
841 need to jump over to, like a so-urgent-right-now bugfix, but don't want
842 to commit or lose your current edits. <code>git stash</code> is there for you.
843 </p>
844
845 <h4>
846 git stash
847 <small>add current changes to the stack</small>
848 </h4>
849
850 <p>Stashing takes the current state of the working directory and index,
851 puts it on a stack for later, and gives you back a clean working directory.
852 It will then leave you at the state of the last commit.
853 </p>
854
855 <p>If you have untracked files, <code>git stash</code> will not include
856 them. You can either stage those files with <code>git add</code> (you don't
857 have to commit) before stashing, or, if you have a recent Git version
858 (1.7.7 or above), you can use <code>git stash -u</code> to also stash also
859 unversioned files.</p>
860
861 <pre>
862 <b>$ git status -s</b>
863 <span class="red">M</span> hello.rb
864 <b>$ git stash</b>
865 Saved working directory and index state WIP on master: 5857ac1 hello with a flower
866 HEAD is now at 5857ac1 hello with a flower
867 <b>$ git status</b>
868 # On branch master
869 nothing to commit (working directory clean)
870 </pre>
871
872 <h4 id="stash-list">
873 git stash list
874 <small>view stashes currently on the stack</small>
875 </h4>
876
877 <p>It's helpful to know what you've got stowed on the stash and this is where
878 <code>git stash list</code> comes in. Running this command will display a queue
879 of current stash items.
880 </p>
881
882 <pre>
883 <b>$ git stash list</b>
884 stash@{0}: WIP on master: 5857ac1 hello with a flower
885 </pre>
886
887 <p>The last item added onto the stash will be referenced by
888 <code>stash@{0}</code> and increment those already there by one.
889 </p>
890
891 <pre>
892 <b>$ vim hello.rb</b>
893 <b>$ git commit -am 'it stops raining'</b>
894 [master ee2d2c6] it stops raining
895 1 files changed, 1 insertions(+), 1 deletions(-)
896 <b>$ vim hello.rb</b>
897 <b>$ git stash</b>
898 Saved working directory and index state WIP on master: ee2d2c6 it stops raining
899 HEAD is now at ee2d2c6 it stops raining
900 <b>$ git stash list</b>
901 stash@{0}: WIP on master: ee2d2c6 it stops raining
902 stash@{1}: WIP on master: 5857ac1 hello with a flower
903 </pre>
904
905 <h4 id="stash-apply">
906 git stash apply
907 <small>grab the item from the stash list and apply to current working directory</small>
908 </h4>
909
910 <p>When you're ready to continue from where you left off, run the
911 <code>git stash apply</code> command to bring back the saved changes
912 onto the working directory.
913 </p>
914
915 <pre>
916 <b>$ git stash apply</b>
917 # On branch master
918 # Changes not staged for commit:
919 # (use "git add &lt;file>..." to update what will be committed)
920 # (use "git checkout -- &lt;file>..." to discard changes in working directory)
921 #
922 # <span class="red">modified: hello.rb</span>
923 #
924 no changes added to commit (use "git add" and/or "git commit -a")
925 </pre>
926
927 <p>By default it will reapply the last added stash item to the working
928 directory. This will be the item referenced by <code>stash@{0}</code>.
929 You can grab another stash item instead if you reference it in the arguments
930 list. For example, <code>git stash apply stash@{1}</code> will apply the item
931 referenced by <code>stash@{1}</code>.
932 </p>
933
934 <p>If you also want to remove the item from the stack at the same time,
935 use <code>git stash pop</code> instead.
936 </p>
937
938 <h4 id="stash-drop">
939 git stash drop
940 <small>remove an item from the stash list</small>
941 </h4>
942
943 <p>When you're done with the stashed item and/or want to remove it from the
944 list, run the <code>git stash drop</code> command. By default this will
945 remove the last added stash item. You can also remove a specific item if
946 you include it as an argument.
947 </p>
948
949 <p>In this example, our stash list has at least two items, but we want
950 to get rid of the item added before last, which is referenced by
951 <code>stash@{1}</code>.
952 </p>
953
954 <pre>
955 <b>$ git stash drop stash@{1}</b>
956 Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
957 </pre>
958
959 <p>If you want to remove of all the stored items, just run
960 the <code>git stash clear</code> command. But only do this if you're
961 sure you're done with the stash.
962 </p>
963
964 <p class="nutshell">
965 <strong>In a nutshell</strong>, run <code>git stash</code> to quickly save
966 some changes that you're not ready to commit or save, but want to come
967 back to while you work on something else.
968 </p>
969
970 </div>
971 </div>
972
973 <p><a class="page-button next-page" href="/branching">On to Branching and Merging &#187;</a></p>