Version control systems make collaboration seamless in software development. Git is a version control system used for source code management. It is amongst others not only the most popular among developers but offers excellent features to help in the tracking and managing of software. Git interacts with software using specific commands via the command line interface to perform various tasks ranging from initialising a git repository to keeping track of every step of the development process. In this article, some important git commands including git init, git add and git commit will be explained with an emphasis on git commit.

GIT INIT

This command is used to initialise a git repository which is basically telling git to keep track of the repository, to “keep an eye out for changes” in the repository. This is the first step to managing source code with git. The syntax for this is git init <repository name>.

GIT ADD

This command is used to track file(s) in the git repository. This command tells git to take record of specific file(s) for the next commit. Git takes a snapshot of the file(s) pending the next commit, only file(s) succeeding this command will be recorded by git. The syntax for this is git add <file name> or git add .. Using the period symbol (`.`) in place of file name tracks all files instead of a single file. This is preferred in instances where tracking multiple files is needed, instead of having to repeatedly run a single command with the different file names or type out multiple file names, git add . is more efficient.

GIT COMMIT

This command is used to save the recorded changes made using the git add command. This command however takes at least two additional arguments. The most common syntax for this is git commit -m “write commit message here”. The -m flag means message which is recorded in the quotation marks that comes right after the flag. It is important to note that the commit message should always be written in the imperative form that is statements that gives a command or makes a request from the reader. This would be a quick way to make a commit, but there are times when a more detailed commit message is needed beyond a simple statement.

CRAFTING GREAT GIT COMMIT MESSAGE

An effective git commit message consists of the right amount of information written properly. Conventional commits defines the specification that provides easy rules for creating useful commit history that makes it easy for you, your project collaborators and/or git as the case may be to understand and possibly perform tasks with your git commits. These specifications automatically generate change logs, can help determine semantic version bumps based on your commit and establish a properly structured commit history. Some benefits of properly structuring a git commit are:

1. It makes debugging easier using commit history.

2. It helps a developer contribute meaningfully to open source software.

3. It makes collaboration easier and enables better use of even more git commands like git reset, git revert and so on.

4. It identifies a developer as a good collaborator as a good commit message saves project maintainer time because pull requests are clearer and faster to review.

Any git commit message can be split into five as specified by conventional commits. The syntax for this is:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

1. <type>: This is the first part of a commit message and is used to communicate the intent of your change. This usually takes the value fix for when the commit addresses a bug, feat for when the commit includes a feature you worked on, build, chore, style, refactor, test, ci or docs as the case may be.

2. [optional scope]: This is the second part of the commit message, it provides additional information to the <type> value passed. Best practice for writing the scope is usually a noun surrounded by parantheses eg feat(user): introduce anonymous comment feature. You can also indicate if this commit type contains and change that may break the code by using an exclamation mark (!) after the closing paranthesis ()) and before the colon (:). This part of a commit message is optional.

3. <description>: The third part of the commit message is the description which is what is written in a one-liner git commit message using the -m flag. The description should be written in the imperative form, a great test for the imperative form of a commit message will be to insert it in this phrase - “When implemented, this commit will <insert commit message here>”. The sentence should be grammatically correct if the commit message is in the imperative form. It should be short and precise. This part of the commit message is in actual sense the commit title.

4. [optional body]: The fourth part of the commit message is an optional body which further explains the commit description, it follows the commit title with one blank line. This is optional as well as not all commits are complex that they require further description.

Additionally, the 50 72 git commit rule suggests that the <description> is limited to 50 characters while the [optional body] should wrap at 72 characters.

1. [optional footer(s)]: The fifth part of a commit message is the footer. It is usually separated from the body by one blank line and contains an issue tracker. The footer is optional as well considering not all commits are directly addressing an issue and need to reference and issue ID. This section can also be used to document metadata options eg indicating what method you used for development.

Run git commit in the command line interface without any argument to prompt the git commit message full edit mode.

A common confusion around making a git commit is how often to make a commit which raises the question: how much change deserves its own commit? The best opinion I’ve come across so far concerning this is that a unit of (functional) change is equivalent to a single commit. This way you can easily reverse to a previous version of the code without doing any serious “damage”.

The git commit command is flexible enough to take a variety of flags and even a combination of flags to perform various tasks. Some other git commands can give insight using the git commit command. Some useful related git commit commands are:

• git commit -v: this commands shows the status of files, which ones have or haven’t been staged for commit as well as gives an insight or context to what the content of the commit should be.

• git commit —amend: this command is used to add newly tracked files to the previous commit

• git commit —amend -v: this command is used to add newly tracked files to previous commit and have a detailed view of what is being added to the previous commit, the commit message of the previous commit can be updated using this command.

• git commit —amend —no-edit: this is used to add new files to previous commit without changing the commit message.

• git show: this is used to see the latest commits.

• git log: this displays all the commits for the current working repository, this can take additional flags like —oneline, —stat or —patch to display more specific information about the commit history.

• git blame: this is used to view the changes in a file line by line as well as see who changed what.

You can read more on Conventional Commits [here](https://www.conventionalcommits.org/en/v1.0.0/).