The Magic of Empty Git Commit

Empty commits play a significant role in enhancing version control workflows. Although seemingly counterintuitive, they offer valuable benefits for documentation, triggering automation. In this short guide, we'll demonstrate how to create and push an empty commit using Git.

Step 1: Initialize a Git Repository
If you haven't already, navigate to your project directory and initialize a Git repository with the following command:

$ git init

Step 2: Create the Empty Commit
To create an empty commit, use the following command:

$ git commit --allow-empty -m "Empty commit"

The --allow-empty flag allows an empty commit, and the -m flag is used to specify a commit message. Feel free to replace "Empty commit" with a meaningful message describing the purpose of the commit.

Step 3: Push the Empty Commit
To push the empty commit to the remote repository, use the command:

$ git push origin <branch-name>

Replace <branch-name> with the name of the branch you want to push the commit to, such as "main" or "develop."

Conclusion:
Empty commits might seem unusual, but they offer significant advantages in managing version control. By documenting milestones, triggering automation processes, and maintaining codebase stability, empty commits can improve collaboration and project management. It is important to note that empty commits should be used specifically in Pull Requests/Merge Requests to avoid cluttering the commit history of the main/production branch.

Comments

[jazzdup]

I hope you have also tried: Automated AI commits maybe more interesting.

[radhe021]

Thanks for sharing !

[Ellis]

Git is a total mess. One more, one less? Meh.

[Sharmila kannan]

I have known only few command in git, it was new to me and got some knowledge, thank you

[Hinara]

Okay so I am thinking that it is not a good idea to create a empty meaning because a commit name is meant to describe it's change so if you don't do any changes there should not be a commit name so no commit at all.
However, I don't have enough information on why you are using them to trigger CI
I am assuming that you are using GitHub in my recommandation

1. To save CI usage Then, make a draft PR and convert it to a regular PR only when it is ready to merge, and make your CI run only on regular open PR
2. To manage external dependency update (fetching external update data) Not a really good idea because that means that your build are not reproducible which can be a big deal when you are trying to debug
3. To tell your CI that you want to merge you PR, and the CI is the one doing the merge This one is more tricky but can be setup by multiple way like auto merging when the PR is approved, or just use a specific message in a PR to trigger a hook which will trigger the CI / renaming your PR with some kind of tag like [READY] With all those solution you should be able to avoid having to make empty commit for whatever reason. And if you need a commit to specify a new version of your product, just use tags please ! As your argument of a company with XXXX salaries it is not an argument. Using a system because "it works" is done by all company whatever their size and whatever the solution is good or not, as long as it works and is not too much of a painpoint they will not bother to change. That why somme company are still using VERY OUTDATED version of some software, because it works and as long as it does not impact the business the will keep it as is

[9to5OpenSource]

Awesome

[Pradumna Saraf]

Thank you.

[Shravan Kumar B]

Empty commits are useful in cases where you want to generate builds some change in sub module projects or dependency projects, so that latest build includes those build.

[burmanp]

Wish i knew this allow empty flag before making a redundant space to make a ci trigger commit last week. Thanks for sharing.

[Raja Nagendra Kumar]

Can Tagging be another alternative to this..

git-scm.com/book/en/v2/Git-Basics-...