Consider I’m working on a branch feat-1
implementing a new feature.
I’m confused what to prefix each commit with on that branch. Should they all be prefixed with feat:
(after all, they are all part of implementing a new feature), or should it only be the last commit that’s prefixed with feat:
?
It’s almost impossible to decide whether a commit is the last commit on a branch, and I often find myself going back fixing bugs, introducing new commits, after I thought I made the last commit.
So, I end up with a commit history, like:
infra: adding server
format(ci): fix format of files
feat: implementing feature
ci: adding workflows
fix: bugs in feature
feat: add more functionality
feat: all done
This might be intermixed with chore:
s and wip:
s.
While, the specification tell us how to “tag” individual commits, I have a hard time translating it to the real world, where multiple commits implement a feature.
https://www.conventionalcommits.org/en/v1.0.0/
4
If you’re working in branches, I’d strongly recommend squashing your commits when you merge into your integration branch. At the very least, I’d use interactive rebasing to clean up the commits on the feature branch prior to merging, leaving only the most relevant commits in the history of the integration branch – commits that fix bugs in the newly developed feature, for example, don’t mean that much once the working feature is in the integration branch.
If you take the approach of interactively rebasing or squashing when merging to the integration branch, you could consider not using the Conventional Commits annotations for work-in-progress commits that you may make since those commit messages would be removed or changed anyway. Only the commits that end up in the integration branch would need to conform to the standard.
Ewan’s answer also brings out a very good point. Not everything needs to be captured in commit messages. Pull requests are a great place to collect a bunch of commits and describe the rational behind changes. In my experience, tools like GitHub and Bitbucket relate the merge commit to the pull request for traceability. Issue trackers also provide a good place for documenting things about a feature over commits. Similarly, both commits and pull requests can be linked to issues. Although Conventional Commits can be helpful, it’s not the whole story.
3
While, the specification tell us how to “tag” individual commits, I
have a hard time translating it to the real world, where multiple
commits implement a feature.
I think you hit the nail on the head here, If you try and put this kind of knowledge in a commit message, rather than say a linked ticket or PR description then you force yourself into making bigger, tested commits. Rather than the old adage of commit fast and often.
If you try and make your commits “neat” then I think you lose some fundamental benefits of source control. Sharing your code, seeing changes that you can undo, seeing the journey you took.
There are plenty of other places you can use to make “neat” messages. merges, pull requests and a ticketing system are better at this than commit messages