Skip to content

Commit Changes (git commit)

What Will We Learn?

This is the content of the details.

Markdown is supported.

What Happens When You Commit Changes?

Committing means like creating new checkpoint of your project. When you commit changes using git commit, Git takes whatever is currently staged (with git add) and creates the snapshot of those staged changes alongwith the metadata about the author (user.name and user.email config) making changes, timestamp and also the commit message explaining why the change was made. Git also adds the reference to the parent commit. These are all stored as commit object in .git/objects directory.

Visualizing Commits 

    flowchart RL
    B --> A
    C --> B

Each letter here represents a commit which points to the previous parent. When new commit D is created, it points back to the parent C.

    flowchart RL
    B --> A
    C --> B
    D --> C

How to Commit Changes?

The basic usage of git commit is:

git commit

It opens your default editor where you write your commit message to explain why the change was made.

If you want to include message directly in the command line, use -m option:

git commit -m "content: add How to Commit"

You can check what the commit will do without actually committing using --dry-run option:

git commit --dry-run

You can also replace the previous commit with new one including both previous and current changes using --amend option:

git commit --amend -m "content: add How to Commit with `--amend` option"

Warning

Ammending commit can introduces confusion as it alters the history especially, in collaborative environments.

There is also --no-edit option for --amend in case you don’t want to edit commit message. It will do all the job --amend does but keep the same commit message:

git commit --amend --no-edit

What to Write in Commit Message?

The commit message you write should explain why the certain change was introduced. So, don’t treat it as formality as it is one of the useful part in history tracking and even bug fixing. Before committing, Ask yourself:

Will I understand what changes were made if I read this commit message six month later?

Commit message should be clear and concise and it’s better to follow common conventions. Most of the industry standard commit message are written in three parts: Subject-Body-Footer where Body and Footer could be optional if Subject itself is enough to explain the change.

Tip

The most important thing is consistency i.e. using similar formats and conventions throughout the project commits.

Commit Message Structure

As said earlier, a good commit message should use Subject-Body-Footer structure.

Subject

  • Use Imparative: For example, “Add content” instead of “Content added”
  • Capitalizing the first letter sounds professional
  • Leaving out periods often make clean commit message
  • Don’t use vague words like “fix”, “add”, “update” only without explaining changes, use them as prefix instead. For example: “Fix: change return type of myfunc from int to float”

A good subject line can be:

Add content: How to write good subject line

Body

Body should explain why and what changed. If it has any caveats and gotchas, you should include them too. You can use bullets points and even markdown style syntax for this explanatory part.

An example can be:

Add content: How to write good subject line

This content explains different ways of writing good subject line in a commit message like:
- being clear and concise
- use of imparative sentences
- capitalizing first word, etc.

Footer

If there is any related issues, commits, references, etc. you can include them in footer section using keywords like “Related Issues”, “Fixes”, “References”, “Related to”, etc.

An example can be:

Add content: How to write good subject line

This content explains different ways of writing good subject line in a commit message like:
- being clear and concise
- use of imparative sentences
- capitalizing first word, etc.

Related to: audience request on youtube video [Commit Best Practices](https://www.youtube.com/watch?v=abcXyZpqRm`)

Note

Remember to separate each section with at least one blank line.

Committing Best Practices

  • Commit atomically i.e. commit after meaningful checkpoints
  • Commit often to keep good track of history but avoid committing every minor change like: fixing one typo
  • Use git status, git diff, etc. to see what changes the commit will introduce and even dry run with git commit --dry-run
  • Introduce branches for features instead of overwhelming main branch for everything, commits will look more organized this way

Avoid While Committing

  • Don’t overexplain things like an essay. Explain in brief.
  • Avoid grammatical errors as it may sound unprofessional.
  • Don’t forget to reference related issues or any related things.
  • Never use generic messages like “Updated content”, be short and precise on what are you trying to achieve.
Last updated on
Checking Git Status (git status)