+ In Git, you have to add file contents to your staging area before you
+ can commit them. If the file is new, you can run git add
+ to initially add the file to your staging area, but even if the file
+ is already "tracked" - ie, it was in your last commit - you still need
+ to call git add to add new modifications to your staging
+ area. Let's see a few examples of this.
+
Going back to our Hello World example, once we've initiated the project,
+ we would now start adding our files to it and we would do that with
+ git add. We can use git status to see what the
+ state of our project is.
+
+$ git status -s +?? README +?? hello.rb ++ + So right now we have two untracked files. We can now add them. + +
+$ git add README hello.rb ++ + Now if we run
git status again, we'll see that they've been
+ added.
+
++$ git status -s +A README +A hello.rb ++ +
OK, so now if we edit one of these files and run git status
+ again, we will see something odd.
+$ vim README +$ git status -s +AM README +A hello.rb ++ +
The 'AM' status means that the file has been modified on disk since we
+ last added it. This means that if we commit our snapshot right now, we will
+ be recording the version of the file when we last ran git add,
+ not the version that is on our disk. Git does not assume that what the file
+ looks like on disk is neccesarily what you want to snapshot - you have to
+ tell Git with the git add command.
+
+ In a nutshell,
+ you run git add on a file when you want to
+ include whatever changes you've made to it in your next commit snapshot.
+ Anything you've changed that is not added will not be included - this means
+ you can craft your snapshots with a bit more precision than most other SCM
+ systems.
For a very interesting example of using this flexibility to stage only
+ parts of modified files at a time, see the '-p' option to
+ git add in the Pro Git book.
As you saw in the git add section, in order to see what the
+ status of your staging area is compared to the code in your working
+ directory, you can run the git status command. I demonstrated
+ using it with the -s option, which gives you short output.
+ Without that flag, the git status command will give you more
+ context and hints. Here is the same status output with and without the
+ -s. The short output looks like this:
+
+$ git status -s +AM README +A hello.rb ++ + Where the same status with the long output looks like this: + +
+$ git status +# On branch master +# +# Initial commit +# +# Changes to be committed: +# (use "git rm --cached+ +..." to unstage) +# +# new file: README +# new file: hello.rb +# +# Changed but not updated: +# (use "git add ..." to update what will be committed) +# (use "git checkout -- ..." to discard changes in working directory) +# +# modified: README +# +
You can easily see how much more compact the short output is, but the + long output has useful tips and hints as to what commands you may want to + use next. +
+ +Git will also tell you about files that were deleted since your last + commit or files that were modified or staged since your last commit.
+ ++$ git status -s +M README + D hello.rb ++ + You can see there are two columns in the short status output. The first + column is for the staging area, the second is for the working directory. + So for example, if you have the README file staged and then you modify + it again without running
git add a second time, you'll see
+ this:
+
++$ git status -s +MM README + D hello.rb ++
+ In a nutshell,
+ you run git status to see if anything has been modified
+ and/or staged since your last commit so you can decide if you want to
+ commit a new snapshot and what will be recorded in it.
+
Each section will link to the next section, so it can be used - as a tutorial. Every page will also link to the more in-depth - offical Git documentation to learn more about any of the commands. - First, we'll start with thinking about source code management like - Git does. + as a tutorial. Every page will also link to more in-depth + Git documentation such as the offical manual pages and relevant + sections in the Pro Git book, so you can learn more about any of + the commands. First, we'll start with thinking about source code + management like Git does.