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.
Top comments (60)
I never used empty commits, actually didn't even know it was possible.
Still, I'm not totally sure that can help more to document than a well written commit with the relative code; and for triggering automations, most platforms gives the chance to trigger them manually, so no need for an empty commit to do that. Maybe I'm the one who's losing the point here, I'm really open and curious to better understand this empty-commit thing.
Still, thank you for the article, it's indeed really interesting, I learnt something new
Empty commits are used in the PR. I have seen projects like Kubernetes and Flutter use this for triggering the CI and tests.
Oh nice, it makes everything clearer, thank you! This makes actually more sense to me now :D Thank you for the clarification!
this is so wrong.. if you want to trigger the CI just push the button in whatever platform you're using (Azure, gitlab, github, etc)
Empty commits are a bad practice.
I disagree. Read this
dev.to/pradumnasaraf/comment/2810p
I already read thst. it's ok, you have the right to be wrong. If you dont have access to run a CI it's just because you don't have the right level of access to those tools. You could argue that you squash commits before merge but you don't.. Empty commits are just a patch for (in that example) poor permission or access management.
I already read that. Empty commits are wrong. You are using empty commits as a patch to poor permission manager on your projects. Sorry but I will never agree on that.
You git behavior is wrong. You have the right to be wrong but don't spread the word. Also you could argue that you squash commits before merge but you don't because the underneath problem is that you don't know how to use git.
I'll let you fight on a 100.000 people companies dealing with critical secret informations to change their permission policies so you can run a CI by yourself. I'll also let you explain Linus Torvalds why he introduced a wrong feature in its product. Could be an interesting debate 😂
Anyway, no feature are wrong. Some feature are badly used and some feature are useful only in very specific context. If your pipeline is triggered only when a push is done, if you cannot push force the master and if you cannot manually trigger the pipeline, then I don't see any other solution than adding an empty commit on top of the branch.
But the not empty commit would yield the same results, as the triggers are push, merge and tag. So the content of the commit would have no bearing on the ability to trigger anything.
I have 23 projects all running automated CI across 3 separate CIs with test, code analysis, deployments of web and backend services, mobile apps and while I’ve known for almost 20 years about an empty commit, the not empty one already does it.
Have you ever made a change to some external setting and wanted to run the pipeline?
I know I have and I've made countless commits where I've simply changed a comment or indentation so I've got something to push. Empty commits would save those pointless changes to the file.
You could definitely re run them from the UI but that means finding the right tab, then the right pipeline, who knows how many clicks. I think I'd be quicker from the console and I can stay in the code context if I've got more work to do.
Yeah, I have shortcuts for basically everything, and I would rather leave the code than add literal junk into my commit history.
Like sure, it would make sense if there was no other way like a public repo where I have no access to the run button, but when I do, I will do it properly, which when I do, is not not push junk into my commit history.
Agreed 1000% with you Ben. The only person who has worked in that environment can understand the importance.
Also, about the UI, on projects with hundreds of maintainers, don't give direct access to CI or third-party buttons/mutual triggers. Bots are used to merge the PRs and empty commit is the only way to re-run those.
I agree with Ben too! It actually happens to add a space just to be able to create a new commit and re-run certain processe that are not necessarely easy to get started in different ways.
I still wouldn't abuse empty commits, but they appear to be further more useful of what they seemed at first sight
What do you mean used in the PR? How are they used in the PR? Do you mean triggering the re-running of PR checks so they somehow pass?
But what would a message for an empty commit say, and does that somehow mark it to not show up in the merge of the PR? Or do you mean this limits you to use the squash option to merge the PR?
My use of empty commit is I have an alias “git note” to add personal notes as commits. I also make the initial commit an empty one for new repos.
While there might be edge cases for empty commits, it really is good practice to always provide context for commits with a concise message. Having said that, I'm curious if anyone uses empty commit messages in a production environment.
We often need to do it to rerun broken pipelines... due a messy architecture we have at work a pipeline dependent on subpipelines and 3rd party projects pipelines. Sometimes, cleaning the caches and rerunning it is not enough to solve an issue, so a clean chain needs to be triggered... therefore empty commits. (They are actually used in the MRs so they will be squashed in master).
Empty commits are used in the PR. I have seen projects like Kubernetes and Flutter use this for triggering the CI and tests.
I used empty commit messages often at my last job for 2 main reasons
1) the most useful was setting a clear reset point if things went wrong. When I started a new feature branch I would immediately create a new empty commit. that way reviewing the history after a merge there's a clear line in the sand when new work began. very helpful for figuring out when / where a new bug was introduced
2) as a small rebellion. at a previous company we had git metrics that would measure how many commits per day you had in comparison to your peers. These metrics at a surface level were useless and imo were an over reaction to a few bad apples when the company went fully remote and they just stopped working.
so in retaliation I and a few of my teammates started using empty commits to help pad our numbers (our manager was aware and on board with our small rebellion as he also wasn't a fan of these terrible metrics)
I never even knew this existed. It seems really useful though.
Thank you.
I'm using it when I wish to rerun my CI jobs.
I'm using a repo with template so when I change that repo (the one with templates), then I should rerun my CI and empty commits are really useful then..
Can't you just have the parent ci trigger the child ci.
It's a common feature for most ci vendors
Likewise
which CI do you use, I currently have workflows on GitHub, GCP and Azure, previous company was AWS and they all have buttons to run the pipeline?
I work with GitHub Actions, but on projects with hundreds of maintainers, you don't have direct access to CI or third-party buttons/mutual triggers. Bots are used to merge the PRs and ask for an empty commit to be pushed because that is the only way to rerun the CI.
If you see projects like Kubernetes, Flutter, etc., they also follow the same pattern.
Thanks for the nice article. I certainly have been there where I needed a job run but the only way to trigger it to make a commit that wasn't needed.
For GitHub actions, we have stared using workflow-dispatch , that lets you manually trigger a workflow
Gitlab but the most important part is i'm using templates" : the coding of my job is located in a specific repo, not the one i'm submitting.
If (with gitlab) I rerun my CI the template is reused from a cache even if i'm update my template repo.
GitLab will take my updated template only with a new commit. This is why i'm using an empty commit.
Great article! This clarifies a lot about the practical utility of empty commits. I have a question though, is there a specific scenario where using empty commits might be discouraged or considered bad practice? I'm wondering if there are any 'dos and don'ts' when it comes to using empty commits in a collaborative environment.
Thank you. Yes, you should not be using it on the
mainbranch and should only use it on PRs.Possibly, one exception for the not-on
mainrule: empty initial commit on a new repo.What ? ( ˙▿˙ )
Nobody has ever told me this before.
Learned something new.
Thank you.
Can Tagging be another alternative to this..
git-scm.com/book/en/v2/Git-Basics-...
Wish i knew this allow empty flag before making a redundant space to make a ci trigger commit last week. Thanks for sharing.
Gret one. Learned something new
Thank you
Awesome
Thank you.
I don't see an useful purpose for this, unless the sheer curiosity.
It will just add more blank entries to the history, and if you have lots and lots of them, it will make to search for useful entries more difficult.
I suppose you haven't worked in teams with hundreds of maintainers, where bots are used to merge the PRs and ask for an empty commit to be pushed because that is the only way to rerun the CI.
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
Did you know you can choose to commit a file with the exact same contents over multiple commits, without worrying about needing to rebase or address conflicts?
I only found out while using GitHub API via JS. I even checked their UI to see if behind the scenes it was an empty commit. It was not.
Lots of odd things you can do with git. Likely there are very good reasons you should not though 😉
Check out projects like Kubernetes, Flutter, etc., and you will understand why you need this in PRs. 😉
Thanks for sharing !
I hope you have also tried: Automated AI commits maybe more interesting.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more