If we don't want the full diff output, but we want more than the
+ git status output, we can use the --stat
+ option, which will give us a summary of changes instead. Here is the
+ same example as above, but using the --stat option instead.
+
+$ git status -s +MM hello.rb +$ git diff --stat + hello.rb | 1 + + 1 files changed, 1 insertions(+), 0 deletions(-) +$ git diff --cached --stat + hello.rb | 2 +- + 1 files changed, 1 insertions(+), 1 deletions(-) +$ git diff HEAD --stat + hello.rb | 3 ++- + 1 files changed, 2 insertions(+), 1 deletions(-) ++
You can also provide a file path at the end of any of these options
to limit the diff output to a specific file or subdirectory.
@@ -372,5 +397,175 @@ index 2aabb6e..2ae9ba4 100644
+
Now that you have staged the content you want to snapshot with the
+ git add command, you run git commit to actually
+ record the snapshot. Let's stage and commit all the changes to our
+ hello.rb file. In this first example, we'll use the
+ -m option to provide the commit message on the command line.
+
+$ git add hello.rb
+$ git status -s
+M hello.rb
+$ git commit -m 'my hola mundo changes'
+[master 68aa034] my hola mundo changes
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+
+ Now we have recorded the snapshot. If we run git status
+ again, we will see that we have a "clean working directory", which means
+ that we have not made any changes since our last commit - there is no
+ un-snapshotted work in our checkout.
+$ git status +# On branch master +nothing to commit (working directory clean) ++ +
If you leave off the -m option, Git will try to open a
+ text editor for you to write your commit message. In vim,
+ which it will default to if it can find nothing else in your settings,
+ the screen might look something like this:
+
+ +# Please enter the commit message for your changes. Lines starting +# with '#' will be ignored, and an empty message aborts the commit. +# On branch master +# Changes to be committed: +# (use "git reset HEAD+ +..." to unstage) +# +# modified: hello.rb +# +~ +~ +".git/COMMIT_EDITMSG" 9L, 257C +
At this point you add your actual commit message at the top of the
+ document. Any lines starting with '#' will be ignored - Git will put
+ the output of the git status command in there for you as
+ a reminder of what you have modified and staged.
In general, it's very important to write a good commit message. + For open source projects, it's generally a rule to write your message + more or less in this format:
+ ++Short (50 chars or less) summary of changes + +More detailed explanatory text, if necessary. Wrap it to about 72 +characters or so. In some contexts, the first line is treated as the +subject of an email and the rest of the text as the body. The blank +line separating the summary from the body is critical (unless you omit +the body entirely); some git tools can get confused if you run the +two together. + +Further paragraphs come after blank lines. + + - Bullet points are okay, too + + - Typically a hyphen or asterisk is used for the bullet, preceded by a + single space, with blank lines in between, but conventions vary + here + +# Please enter the commit message for your changes. Lines starting +# with '#' will be ignored, and an empty message aborts the commit. +# On branch master +# Changes to be committed: +# (use "git reset HEAD+ +..." to unstage) +# +# modified: hello.rb +# +~ +~ +~ +".git/COMMIT_EDITMSG" 25L, 884C written +
+ The commit message is very important. Since much of the power of + Git is this flexibility in carefully crafting commits locally and then + sharing them later, it is very powerful to be able to write three or + four commits of logically seperate changes so that your work may be more + easily peer reviewed. Since there is a seperation between committing and + pushing those changes, do take the time to make it easier for the people + you are working with to see what you've done by putting each logically + seperate change in a seperate commit with a nice commit message so it + is easier for them to see what you are doing and why.
+ +If you think the git add stage of the workflow is too
+ cumbersome, Git allows you to skip that part with the -a
+ option. This basically tells Git to run git add on any file
+ that is "tracked" - that is, any file that was in your last commit and
+ has been modified. This allows you to do a more Subversion style workflow
+ if you want, simply editing files and then running git commit -a
+ when you want to snapshot everything that has been changed. You still need
+ to run git add to start tracking new files, though, just like
+ Subversion.
+
+$ vim hello.rb +$ git status -s + M hello.rb +$ git commit -m 'changes to hello file' +# On branch master +# Changed but not updated: +# (use "git add+ +..." to update what will be committed) +# (use "git checkout -- ..." to discard changes in working directory) +# +# modified: hello.rb +# +no changes added to commit (use "git add" and/or "git commit -a") +$ git commit -am 'changes to hello file' +[master 78b2670] changes to hello file + 1 files changed, 2 insertions(+), 1 deletions(-) +
Notice how if you don't stage any changes and then run
+ git commit, Git will simply give you the output of the
+ git status command, reminding you that nothing is staged.
+ I've highlighted the important part of that message, saying that nothing
+ is added to be committed. If you use -a, it will add and
+ commit everything at once.
+
This now lets you complete the entire snapshotting workflow - you
+ make changes to your files, then use git add to stage
+ files you want to change, git status and git diff
+ to see what you've changed, and then finally git commit
+ to actually record the snapshot forever.
+ In a nutshell,
+ you run git commit to record the snapshot of your staged
+ content. This snapshot can then be compared, shared and reverted to
+ if you need to.
+