Quick Links
Summary
The Git commit command stores copies of the changes from your working directory in your Git repository. But it can also be used to amend existing commits and to revert commits, too.
A basic requirement of any version control system is to store different versions of files for you. In Git, the command that does this iscommit. Here’s everything you need to know.
What Is a Commit in Git?
Commits are the series of snapshots made throughout the lifecycle of a project that make up its development history. Commits are what allow us to extract a version of the project as it was at different points in the past. Why is that important?
Version control systems(VCSs) are most commonly used with software source code and development projects. But they can be used successfully with any collection of text files, such asMarkdownfiles containing chapters of a book.
You might not want every file in your project directories to be handled by the VCS, so you need to be able to nominate the files you want to be version controlled. This adds them to the version control view of the project. They’ll be monitored for changes.
Another way to achieve this isto use an ignore list. This tells Git which files, directories, or types of files it should always ignore.
Over time, as new files are added to the project, some will require being added to the version control system. In Git, this is handled by theaddcommand. Actually, theaddcommand does double service, as we’ll see.
In order to maintain a history of the changes that have been made to the project, you’ll periodically ask Git to store a snapshot of the state of the project, using thecommitcommand. This is where theaddcommand reappears in our workflow. We use theaddcommand to tell Git which changed files we want to have included in the snapshot. Then we usecommitto tell Git to create the snapshot.
Configuring the commit Command
Information about the commit is stored with it, so that it’s always possible to know who made the commit, when, and what the commit contains. Some of this metadata is captured at commit-time, such as the commit message.
Metadata relating to the identity of the members of the development team can be configured by each user, to prevent repeatedly providing the same information.
To set your name globally for all repositories on your computer, use this command.
To verify your name has been set, use this command.
If you need to use a different name on a particular repository, change into the project’s directory and use the same command without the–globaloption.
We’ve now got a different default user name for this repository, and our global name is still used for other repositories.
In a similar fashion, we can set an email address either globally or for a single repository by including or omitting the–globaloption.
These settings are held in config files. Global Git settings are held in “~/.gitconfig”, and repository-specific settings are held in the repository’s “.git/config” file.
Thecommitcommand references and uses these values as it operates.
Using the commit Command
The basic use of thecommitcommand is to take the files that are in the staging area, known as the index, and store them as a commit in the currentbranch of the repository.
A Basic Commit
We’ve got a project with a changed file. We’ll use theaddcommand to stage the file, then commit it. We’re using the-m(commit message) option so that we can provide a short description of the purpose of the changes. If we don’t use this option, we’re prompted for a commit message as the commit takes place. It’s more convenient to add one on the command line.
If we use thegit logcommand we canreview the details of the commits, in chronological order, with the most recent commit at the top of the list.
The commits are displayed inless.
The commit has been tagged with the name and email address we provided earlier, and our commit message is recorded too.
Auto-Staging Files
Staging many files can take a little time. A different approach is to use the-A(all) option withadd.
This automatically stages all modified files along with all currently untracked files. The staging of untracked files respects the settings in your “.gitignore” file. Git won’t stage files you’ve told it you don’t want to be included. Finally, files in the index that are no longer in the working directory are removed from the index.
Plainly, the-Aoption can cause a lot to happen all at once. The–dry-runoption gives you a preview of the changes without actually performing them.
In our example, it’ll stage two modified existing files, and two new files. Let’s go ahead and use the-Aoption before we use thecommitcommand.
We can see that altogether four files are changed. Two of them are the newly created files, which are listed.
Staging and Committing at the Same Time
Thecommitcommand has a lowercase-a(all) option. This performs the staging and the committing of files in one step.
Thecommit -aoption stages and commits modified existing files, and removes files from the index if they have been removed from your working directory. It doesn’t automatically stage untracked files.
Like theaddcommand, the commit command has a–dry-runoption that allows you to preview its actions before executing it.
The files are staged and committed for us.
Committing to a Different Branch
If you’ve made some changes to files in your work directory then realize you didn’t checkout the correct branch, you need to get your changes committed to the correct branch without affecting the current branch.
Git doesn’t have a command for committing to a different branch. But you’re able to rectify this situation with a little bit of Git dexterity.
We’ll usethe Gitstashcommandto make a copy of the changes. Then we’ll check out the correct branch and apply the changes from the stash. To apply the stashed changes we’re using thepopcommand rather than theapplycommand. Thepopcommand applies the changes and also removes them from the stash.
We’ve made some changes in our repository’snew-parserbranch. They should have been made in theclassic-parserbranch.
We can now perform acommit, and update this branch.
If we return to thenew-parserbranch we can see that it is up to date, meaning the changes have been removed from your working directory, and your repository and files are in sync.
Making Changes to Commits
If you need to improve your commit message—perhaps you’ve spotted a typo in it—or you forgot to stage a file that should have been included in the commit, you’re able to use the–amendoption to put things right. The caveat is, this shouldn’t be used on commits that have been pushed to a remote repository.
In our last commit message, “fraze” should have been “phrase.” If we usegit logwe can see this.
To correct this, we’ll use the–amendoption like this.
If we usegit logonce more, we can see the old commit has been replaced by a new one with the corrected commit message.
If we want to add a file that we forgot to stage, we can commit that file so that it appears as part of the previous commit.
We’ll useaddto stage the file, then make a commit with the–amendoption. The–no-editoption means we don’t need to provide a new commit message. The previous commit message is retained.
Removing Changes From a Commit
If you’ve inadvertently staged and committed a file that you didn’t intend to, you can remove that file from the commit usingtheresetcommand. We’ll reset the commit back to the staging area, or index. Then we’ll remove the file, and re-commit the rest of the files.
To reset the last commit to the staging area, we use thereset –softcommand.HEAD~is shorthand for “the commit behind the HEAD of the project commit timeline”, or in English, “the last commit.”
To remove the file that shouldn’t have been included, we use thereset –mixedcommand. This resets those changes back into the working directory, recreating the modified file as an unstaged, uncommitted file.
We need to commit the other files that are left in the index.
The other two files that were in the original commit are re-committed for us.
Reverting an Entire Commit
Sometimes undoing an entire commit is the easiest thing to do. It puts your working directory and repository back to the state they were in before you committed.
We need to use the commit’s hashed reference ID. We can find this usinggit log:
Copy that reference and use it in therevertcommand:
This will open your default editor so you’re able to edit a revert message. There is a default message entered for you. You can either use this, or edit it to your liking.
When you’re happy with your revert message, save the file and exit the editor. Innano, you do this with “Ctrl+O”, and “Ctrl+X.”
Usinggit logonce more, we can see that a new commit has been added that undoes the changes of the reverted commit.
The Git Swiss Army Knife
Obviously,commitis one of the most important Git commands. It can do a lot, so there’s a lot to learn. Getting to grips with its lesser-used features is time well spent. When you need to correct a mistake—right now—you’ll be glad you’ve prepared in advance.
