Empty Commit in Git: Great for Triggering CI

The other day I was working on some continuous integration with a Git repository and Azure DevOps. Wanting to test some changes I actually needed to commit something, but I didn’t want to add a space to some Markdown file or something. As it turns out, you can create empty commits in Git which will help you in this case.


I was trying to implement a YAML definition for our CI pipeline and I got into a state where there was no new change to commit, but I did want to trigger a new CI build. You most definitely can go into your build provider and trigger a new one, but that’s a hassle. An in fact, depending on the environment you’re in, you might not even be able to. Maybe the code is open-source, but that doesn’t mean you have control over the build server.

While typing this I actually remember working on the Xamarin.Forms repository. The code and even the build logs are open for everyone, but as you can imagine not everyone is able to go into Azure DevOps and trigger a new build. People would ping you in a comment and I would trigger a new build for them.

Empty Commit to the Rescue

This is where an empty commit comes in handy. And empty commit is a commit without any actual changes. However, they will still show up in your history. So be aware of that! You probably only want to use this in a separate branch and you know that your changes will either be rebased, leaving out these empty ones, or squashed.

The command for an empty commit is very easy. Open up a terminal of your liking and do:

git commit --allow-empty -m "[EMPTY] Relevant commit message here"

If you plan to remove the empty commits later you might want to mark it, like with the [EMPTY] prefix here. But you can put anything in there as the commit message of course.

That’s it! My quick tip for you. BTW, thanks for asking, the build worked after this; yay! ๐Ÿ˜€

Hero image based on: Background photo created by kjpargeter – www.freepik.com

3 thoughts on “Empty Commit in Git: Great for Triggering CI”

    • Hey Alexander!

      Typically you can definitely do that and there is nothing wrong with both. But there might be a scenario where you do not have access to the system that does the builds for you, but you do have access to the Git repository (probably in the form of a PR). Does that make sense?

Comments are closed.