| [ << Working with source code ] | [Top][Contents][Index][ ? ] | [ Compiling >> ] | ||
| [ < Merging branches ] | [ Up : Basic Git procedures ] | [ Understanding commits > ] | ||
3.3.4 Commits
| Understanding commits | ||
| How to make a commit | ||
| Commit messages |
| [ << Working with source code ] | [Top][Contents][Index][ ? ] | [ Compiling >> ] | ||
| [ < Commits ] | [ Up : Commits ] | [ How to make a commit > ] | ||
Understanding commits
Technically, a commit is a single point in the history of a branch, but most developers use the term to mean a commit object, which stores information about a particular revision. A single commit can record changes to multiple source files, and typically represents one logical set of related changes (such as a bug-fix). You can list the ten most recent commits in your current branch with this command:
git log -10 --oneline
If you’re using an older version of Git and get an ‘unrecognized argument’ error, use this instead:
git log -10 --pretty=oneline --abbrev-commit
More interactive lists of the commits on the remote master
branch are available at
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog and
http://git.sv.gnu.org/cgit/lilypond.git/log/.
| [ << Working with source code ] | [Top][Contents][Index][ ? ] | [ Compiling >> ] | ||
| [ < Understanding commits ] | [ Up : Commits ] | [ Commit messages > ] | ||
How to make a commit
Once you have modified some source files in your working directory, you can make a commit with the following procedure:
- Make sure you’ve configured Git properly (see Configuring Git). Check that your changes meet the requirements described in Code style and/or Documentation policy. For advanced edits, you may also want to verify that the changes don’t break the compilation process.
-
Run the following command:
git status
to make sure you’re on the right branch, and to see which files have been modified, added or removed, etc. You may need to tell Git about any files you’ve added by running one of these:
git add file # add untracked file individually git add . # add all untracked files in current directory
After
git add, rungit statusagain to make sure you got everything. You may also need to modify ‘GNUmakefile’. -
Preview the changes about to be committed (to make sure everything
looks right) with:
git diff HEAD
The
HEADargument refers to the most recent commit on the currently checked-out branch. -
Generate the commit with:
git commit -a
The ‘-a’ is short for ‘--all’ which includes modified and deleted files, but only those newly created files that have previously been added.
| [ << Working with source code ] | [Top][Contents][Index][ ? ] | [ Compiling >> ] | ||
| [ < How to make a commit ] | [ Up : Commits ] | [ Patches > ] | ||
Commit messages
When you run the git commit -a command, Git
automatically opens the default text editor so you can enter a
commit message. If you find yourself in a foreign editing
environment, you’re probably in vi or vim. If
you want to switch to an editor you’re more familiar with, quit by
typing :q! and pressing <Enter>. See
Configuring Git for instructions on changing the default
editor.
In any case, Git will open a text file for your commit message that looks 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 <file>..." to unstage) # # modified: working.itexi #
Your commit message should begin with a one-line summary describing the change (no more than 50 characters long), and if necessary a blank line followed by several lines giving the details:
Doc: add Baerenreiter and Henle solo cello suites Added comparison of solo cello suite engravings to new essay with high-res images, fixed cropping on Finale example.
Commit messages often start with a short prefix describing the general location of the changes.
- Doc: and Doc-**: If a commit affects the documentation in English (or in several languages simultaneously) the commit message should be prefixed with “Doc: ”. If the commit affects only one of the translations, the commit message should be prefixed with “Doc-**: ”, where ** is the two-letter language code.
- Web: and Web-**: Commits that affect the website should use “Web: ” for English, and “Web-**: ” for other languages.
- CSS: Commits that change CSS files should use “Web: CSS: ” or “Doc: CSS: ” depending on whether they affect the website or the documentation/manuals.
- Changes to a single file are often prefixed with the name of the file involved.
Visit the links listed in Understanding commits for examples.
| [ << Working with source code ] | [Top][Contents][Index][ ? ] | [ Compiling >> ] | ||
| [ < How to make a commit ] | [ Up : Commits ] | [ Patches > ] | ||