There are characteristics and traits which are associated with a well formed commit (I’m not going to cover them, because it varies), but I’ve seen a pattern with most people who learn git which is that they get through the basics and enough to get out of trouble (usually learned by necessity) and the plateau.

Unless you can commit part of your changes (or even something slightly different to your working copy) you are missing one of the more exciting reasons we like using git so much :)

Say you changed a few lines of your readme file:

diff --git a/README b/README index c3bedea..f6ce713 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ this is the first line - +this is the second line this is the third line - +this is the fouth line this is the fifth line

You can git add README to add all the changes, or you can git add -p README to “patch” the file. I always recommend checking out the git help and get into the habit of checking it for difinitive explanations of how things work. In this case git help add has the following to say about the -p option:

```

-p, –patch

Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.

This effectively runs add –interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details. ```

So running git add -p README will present you with the following:

diff --git a/README b/README index c3bedea..f6ce713 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ this is the first line - +this is the second line this is the third line - +this is the fouth line this is the fifth line Stage this hunk [y,n,q,a,d,/,s,e,?]?

This is basially showing you a “hunk” (chunk) of changes in the readme file and asking you what operation to perform. each of the letters you see on the bottom line are commands, and ? will provide you with an overview:

y - stage this hunk n - do not stage this hunk q - quit; do not stage this hunk or any of the remaining ones a - stage this hunk and all later hunks in the file d - do not stage this hunk or any of the later hunks in the file g - select a hunk to go to / - search for a hunk matching the given regex j - leave this hunk undecided, see next undecided hunk J - leave this hunk undecided, see next hunk k - leave this hunk undecided, see previous undecided hunk K - leave this hunk undecided, see previous hunk s - split the current hunk into smaller hunks e - manually edit the current hunk ? - print help

For this demonstration type s and then enter. This will break the hunk into smaller pieces and show you the first one.

Split into 2 hunks. @@ -1,3 +1,3 @@ this is the first line - +this is the second line this is the third line Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]?

This is great for breaking large changes into smaller ones. Now stage (add) this change by typing y and then enter. You should now be presented with the next hunk:

@@ -3,3 +3,3 @@ this is the third line - +this is the fouth line this is the fifth line Stage this hunk [y,n,q,a,d,/,K,g,e,?]?

Type n and press enter to skip this hunk.

git status should now show that your ready has two change, one staged and one still in your working copy:

``` On branch master Changes to be committed: (use “git reset HEAD ..." to unstage)

modified: README

Changes not staged for commit: (use “git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory)

modified: README ```

This is because you only staged one of the two changes.

You can see which changes will be saved when you commit by running git diff —cached and see what changes will remain in the working copy with git diff.

You can now git commit those changes and get on with your work :)

If you find this useful I encourage you to check out some of the other commands, especially e.