DEV Community

Discussion on: The Magic of Empty Git Commit

Collapse
 
hinara profile image
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

Some comments have been hidden by the post's author - find out more