Empty commits play a significant role in enhancing version control workflows. Although seemingly counterintuitive, they offer valuable benefits for...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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
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.
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.
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.What ? ( ˙▿˙ )
Nobody has ever told me this before.
Learned something new.
Thank you.
Gret one. Learned something new
Thank you
Wish i knew this allow empty flag before making a redundant space to make a ci trigger commit last week. Thanks for sharing.
Can Tagging be another alternative to this..
git-scm.com/book/en/v2/Git-Basics-...
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 have known only few command in git, it was new to me and got some knowledge, thank you
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.
I hope you have also tried: Automated AI commits maybe more interesting.
This is not the solution if you want an automated release using Github Actions for private npm packages.
This is not used to push directly to the main branch and cluttering the git history. It is used in PRs to trigger CI and tests.
Git is a total mess. One more, one less? Meh.
This is exactly why tags exist. You create a tag to indicate something, usually a version release. Don't rely on commits for this. Tags can also be used to trigger specific release builds and such.
As others have pointed out, this can be done manually. You shouldn't have to create commits to trigger it. Someone mentioned third-party or messy pipelines, but then that's an issue and empty commits is not the solution, it's a workaround to a bad solution. This will also create many commits just named "Re-run CI" or something, cluttering the Git history. Looking around for similar posts, this is the only argument can find for empty commits.
The argument that they will be squashed in the MR is something I'm generally against. Cleaning up the Git history before merging is good, preferably with an interactive rebase. But squashing an entire MR into one commit can lose much valuable information in the individual commits that make up the MR. But if you do clean up the commits after yourself then I can accept using them for triggering CI.
How?
I disagree. In larger teams with hundreds of maintainers, you don't have direct access to CI or third-party or mutual triggers. They use bots to merge the PRs and ask to push an empty commit because that is the only way to rerun the CI. Squashing and merging are considered to be 100% beneficial.
If this practice were bad, why would projects like Kubernetes, Flutter, etc., be utilizing it?
I can accept using empty commits to trigger CI, but ideally they should be cleaned up afterwards.
This is an incredibly subjective opinion. Each method has pros and cons
By rebasing I mean that the developer rebases their changes on the target branch, and any feedback and such are edited into the respective commits. It's harder but gets a pretty nice result. The owner can then do a normal merge on the MR, or rebase instead of merge to apply on top.
Linux kernel uses the rebase approach for handling merges, and it works really well at their scale and creates a pleasant Git history. But that is not to say everyone should use it. Why isn't the Linux kernel squashing commits if it's so good? Because that model doesn't work for them.
If it's good practice (empty commits), why isn't it used more widely? Because often it's not required. I don't think it's necessarily bad, but I don't think it should be the go-to method.
Software development is a very subjective field in many aspects around processes and workflows, what some developers consider good, others will consider awful.
This was clearly written by ChatGPT, it doesn't make any sense. The empty commitment here is clearly with the content quality. Specially if you look at the "Stage 2" completely voiding the whole concept of "empty commit", turning it into a regular git commit. It doesn't help anyone.
This is rude behavior, and yes, I have corrected the grammatical errors from the text generated by ChatGPT. However, it is not appropriate to directly accuse someone and claim that it was written by ChatGPT.
I should say it is equally rude to hide replies to the post unless it is abusive. It is always good to mention or add a note that the article was written using AI tools. I understand that the underlying topic is yours only the content part was with the help of AI tools. Not everyone take it that way, and there are quite a lot of junk articles people create just by copying from AI bot, in dev.to. You can take or disregard this feedback.
Anyway I liked the topic you mentioned and something new to me. I will surely explore it! Thanks a lot!
Thank you. Some sentences are on the abusive side, this is why I hide :)
I believe this is a bad practice and I do not recommend to do this at all.
Nope, not a bad practice. Read this
dev.to/pradumnasaraf/comment/2810p
You must stay drunk on writing so reality cannot destroy you.