Git Basics | git commit

Tags:

• Git
• SCM
• VCS

The git commit command

git commit is the command for committing a staged snapshot to the local repository. A committed snapshot can be understood as a safely stored version of the project, and Git will not change it unless you explicitly tell it to. Along with git add, this is one of the most important Git commands.

Although the name is the same, this command is completely different from svn commit. Because the snapshot is committed to the local repository, it does not affect any other Git repository.

Usage

git commit

Commits the staged snapshot. Running this command opens a text editor and asks you to enter a commit message. After entering the message, save the file and exit the editor to complete the commit.

git commit -m "<message>"

Commits the staged snapshot using <message> as the commit message without opening a text editor.

git commit -a

Commits a snapshot of all changes in the working directory. This includes only modifications to tracked files, meaning files that have previously been added to the staging area with git add.

Notes

Snapshots are always committed to the local repository. This is a fundamental difference from SVN, where a working copy is committed to the central repository. Git does not force communication with the central repository before it is needed. Just as the staging area acts as a buffer between the working directory and the local repository, each developer’s local repository acts as a buffer between their work and the central repository.

This creates a major change in the development model for Git users. Instead of committing changes directly to the central repository, developers using Git can accumulate commits in their local repository. Compared with SVN-style collaboration, this has many advantages: developers can split work into small units, keep related commits grouped together, and organize the local repository before publishing to the central repository. As a result, developers can work independently and delay integration with others until the work reaches an appropriate boundary.

Storing snapshots, not differences

There are practical differences between SVN and Git, but beyond that, their underlying structures are based on completely different design ideas. SVN tracks differences between files, while Git’s version management model is based on snapshots. For example, an SVN commit consists of differences from the original files in the repository. Git, on the other hand, records the full content of each file for each command.

Git Tutorial: Storing Snapshots, Not Differences

With this approach, Git does not need to assemble a file from change data when reproducing a specific version. Every version of each file can be obtained immediately from Git’s internal database, which is why most Git operations are much faster than SVN operations.

The snapshot model used by Git has broad effects on every aspect of its version control model, from branching and merging tools to collaborative workflows.

Example

In the following example, assume that you have edited a file named hello.py and are ready to commit it to the local repository. First, use git add to stage the file, and then commit the staged snapshot.

git add hello.py
git commit

Running this command opens a text editor, which can be configured with git config. It shows the list of content to be committed and asks for a commit message:

# 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.py
#

Git does not enforce a strict commit message format, but the standard format is to write a summary of the whole commit in 50 characters or fewer on the first line, leave the second line blank, and describe the changes in more detail from the third line onward. For example:

Change the message displayed by hello.py

- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message

Many developers also tend to write commit messages in the present tense. This makes the history read like a sequence of actions applied to the repository and makes history rewriting easier to understand.