Examples using git-commit lifted from kernel.org
Single File Stage and Record: git-add and git-commit
When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the “index” with git-add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git reset HEAD — <file>, which effectively reverts git-add and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands, git commit (without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:
$ edit hello.c $ git rm goodbye.c $ git add hello.c $ git commit
ShortCut to above for Tracked Files
Instead of staging files after each individual change, you can tell git commit to notice the changes to the files whose contents are tracked in your working tree and do corresponding git add and git rm for you. That is, this example does the same as the earlier example if there is no other change in your working tree:
$ edit hello.c $ rm goodbye.c $ git commit -a
The command git commit -a first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary git add and git rm for you.
After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to git commit. When pathnames are given, the command makes a commit that only records the changes made to the named paths:
$ edit hello.c hello.h $ git add hello.c hello.h $ edit Makefile $ git commit Makefile
This makes a commit that records the modification to Makefile. The changes staged for hello.c and hello.h are not included in the resulting commit. However, their changes are not lost — they are still staged and merely held back. After the above sequence, if you do:
$ git commit
this second commit would record the changes to hello.c and hello.h as expected.
After a merge (initiated by git-merge or git-pull) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with git-status and after fixing them manually in your working tree, you would stage the result as usual with git-add:
$ git status | grep unmerged unmerged: hello.c $ edit hello.c $ git add hello.c
After resolving conflicts and staging the result, git ls-files -u would stop mentioning the conflicted path. When you are done, run git commit to finally record the merge:
$ git commit
As with the case to record your own changes, you can use -a option to save typing. One difference is that during a merge resolution, you cannot use git commit with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see -i option).
Showing changes from previous revision. Removed | Added
