1

If I am working on a single feature, I would usually commit multiple commits. Should every commit start with feat? Or should only 1 commit have the type of feat and use a different type for the other commits?

e.g:

feat: add part 1
test: add part 1 test
feat: add part 2
fix: something in p2
feat: add part 3
1
  • 1
    Does each commit contain a working, compiling sub-feature, or is it just a temporary checkpoint? For instance, if your final feature includes returning some item from a database to an HTTP endpoint, you could have a sub-feature which returns the item from a stub (which could be one commit), then another sub-feature where you fetch the item from the actual database (which could be another commit). Aug 17 at 17:02
4

Looking at the current specification for Conventional Commits, I don't see anything that explicitly identifies what to do in this case. However, I do see a few things that lead me to draw some conclusions on what the best thing to do is.

Conventional Commits are designed to work with Semantic Versioning. A commit identified as feat corresponds to a minor version, a fix commit corresponds to a patch version, and a BREAKING CHANGE represents a major version.

I would first want to understand your branching strategy. If you are committing to trunk, my advice would be different than if you are following Git Flow or GitHub Flow and developing in feature branches.

If you are using feature branches, it doesn't matter. The version number wouldn't increment until after at least one feature branch was merged into the main branch and you could increment the appropriate version once based on the set of commits.

If you are also using feature branches, I'd even suggest editing your commit history or squashing the commit into a single commit of the appropriate type when merging it into the main branch. Perhaps the commit history is useful when reviewing the code (such as during a pull request), but it becomes far less useful once the changes are integrated and you won't work with the individual commits but the change as a whole.

However, if you are committing to the main branch, you may not want your version to increment after every commit and until the feature is complete and I would suggest introducing a new type for the work-in-progress commits and then using feat when the feature is ready to be enabled in one or more environments. I would even be hesitant to use fix for changes that are not ready to be enabled to prevent incrementing the version of software for things that are not ready to be seen by users.

Your release and deployment frequency also play a part here.

If you are practicing continuous deployment, you are going to want to keep track of each set of code. You may choose to only increment the version when there's something new to be enabled and use the commit hash to keep track of which set of code is deployed. Or you may choose to increment the version on every deployment.

If you are bundling commits into planned releases, you can look at the full set of work to decide what version number to increment. Understanding what fixes, features, and breaking changes are part of the released code will affect the version number for the new build.

Of course, if you aren't using Semantic Versioning and are instead using some other versioning scheme, perhaps the nuances of Conventional Commits aren't appropriate for you since you don't need a signal about when to increment which parts of the version identifier. Your team can develop your own rules.

1
  • 2
    I tend to use wip: ... prefixes for commits that don't fix anything or introduce features or documentation, e.g. wip: Added method X and unit tests. I also try to avoid wip: ... commits in any of our mainline branches. I typically do this in my own personal branch, then rebase and squash before pushing or merging into other branches --- regardless of which branching strategy our team uses. I personally like to see one clean feat: ... commit in the shared history of our repository. Aug 17 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.