+ It is also common to recusively add all files in a new project by specifying
+ the current working directory like this: git add .. Since Git
+ will recursively add all files under a directory you give it, if you give it
+ the current working directory, it will simply start tracking every file
+ there. In this case, a git add . would have done the same
+ thing as a git add README hello.rb, or for that matter so would
+ git add *, but that's only because we don't have subdirectories
+ which the * would not recurse into.
+
OK, so now if we edit one of these files and run git status
again, we will see something odd.
@@ -567,5 +578,157 @@ Further paragraphs come after blank lines. +++ ++ + docs + book + + git reset HEAD + unstage changes that you have staged +
+ ++++ +
git resetis probably the most confusing command written + by humans. I've been using Git for years, even wrote a book on it and I + still get confused by what it is going to do at times. So, I'll just + tell you the three specific invocations of it that are generally + helpful and ask you to blindly use it as I do - because it can be + very useful. +In this case, we can use it to unstage something that you have + accidentally staged. Let's say that you have modified two files and want + to record them into two different commits. You should stage and commit + one, then stage and commit the other. If you accidentally stage both of + them, how do you un-stage one? You do it with +
+ +git reset HEAD -- file. Technically here you don't have to + add the--- it is used to tell Git when you have stopped + listing options and are now listing file paths, but it's probably good to + get into the habit of using it to seperate options from paths even if you + don't need to. +So, let's see what it looks like to unstage something. Here we have + two files that have been modified since our last commit. We will stage + both, then unstage one of them.
+ ++$ git status -s + M README + M hello.rb +$ git add . +$ git status -s +M README +M hello.rb +$ git reset HEAD -- hello.rb +Unstaged changes after reset: +M hello.rb +$ git status -s +M README + M hello.rb ++ +Now you can run a
+ +git commit which will just record + the changes to theREADMEfile, not the now unstaged +hello.rb. ++ In case you're curious, what it's actually doing here is it is resetting + the checksum of the entry for that file in the "index" to be what it was + in the last commit. Since
+ +git addchecksums a file and adds + it to the "index",git reset HEADoverwrites that with what + it was before, thereby effectively unstaging it. ++ If you want to be able to just run
+ +git unstage, you can easily + setup an alias in Git. Just run +git config --global alias.unstage "reset HEAD". + Once you have run that, you can then just run +git unstage [file]instead. +If you forget the command to unstage something, Git is helpful in + reminding you in the output of the normal
+ +git status+ command. For example, if you rungit statuswithout + the-swhen you have staged files, it will tell you + how to unstage them:+$ git status +# On branch master +# Changes to be committed: +# (use "git reset HEAD+ +..." to unstage) +# +# modified: README +# modified: hello.rb +# ++ In a nutshell, + you run
+ +git reset HEADto unstage files that you previously + rangit addon and wish to not include in the next commit + snapshot+++ + docs + book + + git rm + remove files from the staging area +
+ ++ +++ +
git rmwill remove entries from the staging area. + This is a bit different fromgit reset HEADwhich "unstages" + files. By "unstage" I mean it reverts the staging area to what was + there before we started modifying things.git rmon the + other hand just kicks the file off the stage entirely, so that it's not + included in the next commit snapshot, thereby effectively deleting it.By default, a
+ +git rm filewill remove the file from the + staging area entirely and also off your disk (the working directory).+ git mv + git rm orig; mv orig new; git add new +
+ ++ Unlike most other version control systems, Git does not track file renames. + Instead, it just tracks the snapshots and then figures out what files were + likely renamed by comparing snapshots. If a file was removed from one + snapshot and another file was added to the next one and the contents are + similar, Git figures it was most likely a rename. So, although the +
+ +git mvcommand exists, it is superfluous - all it does is a +git rm, moves the file on disk, then runs a +git addon the new file. You don't really need to use it, but + if it's easier, feel free. ++ I personally don't use this command that much in it's normal form - to + delete files. It's often easier to just remove the files off your disk and + then run a
+ +git commit -a, which will automatically remove them + from your index, too.+ In a nutshell, + you run
+ + +git rmto remove files from being tracked in Git. It + will also remove them from your working directory.