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).
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)
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
We're a place where coders share, stay up-to-date and grow their careers.
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)