@git / git-reference / commits / c4621c2

basically done with basic

Scott Chacon committed Jun 4, 2010 at 09:41 UTC c4621c278be6b83f958e59bd4ed9494d4b5f43f4
2 files changed +171 -6
_layouts/reference.html
+8 -6
@@ -45,12 +45,12 @@
45 <div class="block">
46 <h3><a href="/basic">Basic Snapshotting</a></h3>
47 <ul>
48 - <li><a href="/basic/add.html">add</a></li>
49 - <li><a href="/basic/status.html">status</a></li>
50 - <li><a href="/basic/diff.html">diff</a></li>
51 - <li><a href="/basic/commit.html">commit</a></li>
52 - <li><a href="/basic/rm-mv.html">rm, mv</a></li>
53 - <li><a href="/basic/reset.html">reset</a></li>
48 + <li><a href="/basic/#add">add</a></li>
49 + <li><a href="/basic/#status">status</a></li>
50 + <li><a href="/basic/#diff">diff</a></li>
51 + <li><a href="/basic/#commit">commit</a></li>
52 + <li><a href="/basic/#reset">reset</a></li>
53 + <li><a href="/basic/#rm-mv">rm, mv</a></li>
54 </ul>
55 </div>
56
@@ -61,6 +61,7 @@
61 <li><a href="/branching/merge.html">merge</a></li>
62 <li><a href="/branching/checkout.html">checkout</a></li>
63 <li><a href="/branching/log.html">log</a></li>
64 + <li><a href="/branching/reset.html">reset</a></li>
65 </ul>
66 </div>
67
@@ -86,6 +87,7 @@
87 <li><a href="/fixing/rebase.html">rebase</a></li>
88 <li><a href="/fixing/revert.html">revert</a></li>
89 <li><a href="/fixing/checkout.html">checkout</a></li>
90 + <li><a href="/fixing/reset.html">reset</a></li>
91 <li><a href="/fixing/cherry-pick.html">cherry-pick</a></li>
92 </ul>
93 </div>
basic/index.html
+163
@@ -77,6 +77,17 @@ layout: reference
77 <span class="green">A</span> hello.rb
78 </pre>
79
80 + <p class="aside">
81 + It is also common to recusively add all files in a new project by specifying
82 + the current working directory like this: <code>git add .</code>. Since Git
83 + will recursively add all files under a directory you give it, if you give it
84 + the current working directory, it will simply start tracking every file
85 + there. In this case, a <code>git add .</code> would have done the same
86 + thing as a <code>git add README hello.rb</code>, or for that matter so would
87 + <code>git add *</code>, but that's only because we don't have subdirectories
88 + which the <code>*</code> would not recurse into.
89 + </p>
90 +
91 <p>OK, so now if we edit one of these files and run <code>git status</code>
92 again, we will see something odd.</p>
93 <pre>
@@ -567,5 +578,157 @@ Further paragraphs come after blank lines.
578 </div>
579 </div>
580
581 +<div class="box">
582 + <h2>
583 + <span class="docs">
584 + <a href="#">docs</a> &nbsp;
585 + <a href="#">book</a>
586 + </span>
587 + <a name="reset">git reset HEAD</a>
588 + <span class="desc">unstage changes that you have staged</span>
589 + </h2>
590 +
591 + <div class="block">
592 + <p><code>git reset</code> is probably the most confusing command written
593 + by humans. I've been using Git for years, even wrote a book on it and I
594 + still get confused by what it is going to do at times. So, I'll just
595 + tell you the three specific invocations of it that are generally
596 + helpful and ask you to blindly use it as I do - because it can be
597 + very useful.
598 + </p>
599 +
600 + <p>In this case, we can use it to unstage something that you have
601 + accidentally staged. Let's say that you have modified two files and want
602 + to record them into two different commits. You should stage and commit
603 + one, then stage and commit the other. If you accidentally stage both of
604 + them, how do you <i>un-</i>stage one? You do it with
605 + <code>git reset HEAD -- file</code>. Technically here you don't have to
606 + add the <code>--</code> - it is used to tell Git when you have stopped
607 + listing options and are now listing file paths, but it's probably good to
608 + get into the habit of using it to seperate options from paths even if you
609 + don't need to.
610 + </p>
611 +
612 + <p>So, let's see what it looks like to unstage something. Here we have
613 + two files that have been modified since our last commit. We will stage
614 + both, then unstage one of them.</p>
615 +
616 +<pre>
617 +<b>$ git status -s</b>
618 + <span class="red">M</span> README
619 + <span class="red">M</span> hello.rb
620 +<b>$ git add .</b>
621 +<b>$ git status -s</b>
622 +<span class="green">M</span> README
623 +<span class="green">M</span> hello.rb
624 +<b>$ git reset HEAD -- hello.rb </b>
625 +Unstaged changes after reset:
626 +M hello.rb
627 +<b>$ git status -s</b>
628 +<span class="green">M</span> README
629 + <span class="red">M</span> hello.rb
630 +</pre>
631 +
632 + <p>Now you can run a <code>git commit</span> which will just record
633 + the changes to the <code>README</code> file, not the now unstaged
634 + <code>hello.rb</code>.
635 + </p>
636 +
637 + <p class="aside">
638 + In case you're curious, what it's actually doing here is it is resetting
639 + the checksum of the entry for that file in the "index" to be what it was
640 + in the last commit. Since <code>git add</code> checksums a file and adds
641 + it to the "index", <code>git reset HEAD</code> overwrites that with what
642 + it was before, thereby effectively unstaging it.
643 + </p>
644 +
645 + <p class="tip">
646 + If you want to be able to just run <code>git unstage</code>, you can easily
647 + setup an alias in Git. Just run
648 + <code>git config --global alias.unstage "reset HEAD"</code>.
649 + Once you have run that, you can then just run
650 + <code>git unstage [file]</code> instead.
651 + </p>
652 +
653 + <p>If you forget the command to unstage something, Git is helpful in
654 + reminding you in the output of the normal <code>git status</code>
655 + command. For example, if you run <code>git status</code> without
656 + the <code>-s</code> when you have staged files, it will tell you
657 + how to unstage them:</p>
658 +
659 +<pre>
660 +<b>$ git status</b>
661 +# On branch master
662 +# Changes to be committed:
663 +# <span class="hl">(use "git reset HEAD <file>..." to unstage)</span>
664 +#
665 +# <span class="green">modified: README</span>
666 +# <span class="green">modified: hello.rb</span>
667 +#
668 +</pre>
669 +
670 + <p class="nutshell">
671 + <strong>In a nutshell</strong>,
672 + you run <code>git reset HEAD</code> to unstage files that you previously
673 + ran <code>git add</code> on and wish to not include in the next commit
674 + snapshot</p>
675 +
676 + </div>
677 +</div>
678 +
679 +<div class="box">
680 + <h2>
681 + <span class="docs">
682 + <a href="#">docs</a> &nbsp;
683 + <a href="#">book</a>
684 + </span>
685 + <a name="rm-mv">git rm</a>
686 + <span class="desc">remove files from the staging area</span>
687 + </h2>
688 +
689 + <div class="block">
690 +
691 + <p><code>git rm</code> will remove entries from the staging area.
692 + This is a bit different from <code>git reset HEAD</code> which "unstages"
693 + files. By "unstage" I mean it reverts the staging area to what was
694 + there before we started modifying things. <code>git rm</code> on the
695 + other hand just kicks the file off the stage entirely, so that it's not
696 + included in the next commit snapshot, thereby effectively deleting it.</p>
697 +
698 + <p>By default, a <code>git rm file</code> will remove the file from the
699 + staging area entirely and also off your disk (the working directory).</p>
700 +
701 + <h4>
702 + git mv
703 + <small>git rm orig; mv orig new; git add new</small>
704 + </h4>
705 +
706 + <p>
707 + Unlike most other version control systems, Git does not track file renames.
708 + Instead, it just tracks the snapshots and then figures out what files were
709 + likely renamed by comparing snapshots. If a file was removed from one
710 + snapshot and another file was added to the next one and the contents are
711 + similar, Git figures it was most likely a rename. So, although the
712 + <code>git mv</code> command exists, it is superfluous - all it does is a
713 + <code>git rm</code>, moves the file on disk, then runs a
714 + <code>git add</code> on the new file. You don't really need to use it, but
715 + if it's easier, feel free.
716 + </p>
717 +
718 + <p class="aside">
719 + I personally don't use this command that much in it's normal form - to
720 + delete files. It's often easier to just remove the files off your disk and
721 + then run a <code>git commit -a</code>, which will automatically remove them
722 + from your index, too.</p>
723 +
724 + <p class="nutshell">
725 + <strong>In a nutshell</strong>,
726 + you run <code>git rm</code> to remove files from being tracked in Git. It
727 + will also remove them from your working directory.</p>
728 + </p>
729 +
730 + </div>
731 +</div>
732 +
733 <p><a href="/basic">On to Branching and Merging &#187;</a></p>
734