Question: What approach have people used for work in progress features? #63

New Issue

GiteaMirror · 2026-02-17T11:41:01-06:00

GiteaMirror commented

2026-02-17 11:41:01 -06:00

Originally created by @longility on GitHub (Mar 31, 2019).

Question: When reviewing the git log history and when I see feat, I have the expectation that a new feature is introduced. However, when we follow more trunk based development, we may have many wip (work in progress) commits for a feature that is not public and does not introduce any breaking changes. The last commit for the feature may be to feature flag enable or make the feature visible once all the wip commits are done. For the wip commits, what approach has been done to commenting? I'm not comfortable using feat when there isn't a complete feature that can be used. I've been doing like wip: add employee component, but not sure how I feel about that.

Any practices or thoughts that are out there?

Originally created by @longility on GitHub (Mar 31, 2019). Question: When reviewing the git log history and when I see `feat`, I have the expectation that a new feature is introduced. However, when we follow more [trunk based development](https://trunkbaseddevelopment.com/branch-by-abstraction/), we may have many wip (work in progress) commits for a feature that is not public and does not introduce any breaking changes. The last commit for the feature may be to feature flag enable or make the feature visible once all the wip commits are done. For the wip commits, what approach has been done to commenting? I'm not comfortable using `feat` when there isn't a complete feature that can be used. I've been doing like `wip: add employee component`, but not sure how I feel about that. Any practices or thoughts that are out there?

GiteaMirror added the question label 2026-02-17 11:41:01 -06:00

GiteaMirror closed this issue

2026-02-17 11:41:02 -06:00

GiteaMirror commented

2026-02-17 11:41:04 -06:00

@stevemao commented on GitHub (Apr 1, 2019):

Duplicate of https://github.com/conventional-commits/conventionalcommits.org/issues/38

@stevemao commented on GitHub (Apr 1, 2019): Duplicate of https://github.com/conventional-commits/conventionalcommits.org/issues/38

GiteaMirror commented

2026-02-17 11:41:04 -06:00

@longility commented on GitHub (Apr 2, 2019):

I'm not sure if I consider it the same as #38, which are commits to a feature branch. A wip commit can go into the master branch and be released and this is acceptable from the trunk based development standpoint. Trunk based development values continuous integration. minimizing merge conflicts, and trying to always stay releasable.

@longility commented on GitHub (Apr 2, 2019): I'm not sure if I consider it the same as #38, which are commits to a feature branch. A wip commit can go into the `master` branch and be released and this is acceptable from the trunk based development standpoint. Trunk based development values continuous integration. minimizing merge conflicts, and trying to always stay releasable.

GiteaMirror commented

2026-02-17 11:41:05 -06:00

@bcoe commented on GitHub (Apr 17, 2019):

@longility if a trunk based development workflow doesn't support the concept of concrete features landing on a master branch, it might be beyond the scope of the problem we're trying to solve with conventional commits -- you could perhaps use this specification as inspiration, and come up with your own set of conventions?

@bcoe commented on GitHub (Apr 17, 2019): @longility if a trunk based development workflow doesn't support the concept of concrete features landing on a master branch, it might be beyond the scope of the problem we're trying to solve with conventional commits -- you could perhaps use this specification as inspiration, and come up with your own set of conventions?

GiteaMirror commented

2026-02-17 11:41:06 -06:00

@damianopetrungaro commented on GitHub (Apr 18, 2019):

@longility as I said:

WIP commits do not have any sense to be written in a proper way IMHO, they will be squashed after your feature branch will be finished.

The point is that one PR should be solved within an atomic commit.
If this is not possible (or a solution is not applicable for your use case), you should always add value to each commit message you write, so also if the PR has 10 commits all of them can be merged to the master without breaking the build.

But if you really do not want to change your way of "when to create a commit" you can use your own commit message type and explain the usage in your documentation :D

@damianopetrungaro commented on GitHub (Apr 18, 2019): @longility as I said: > WIP commits do not have any sense to be written in a proper way IMHO, they will be squashed after your feature branch will be finished. The point is that one PR should be solved within an atomic commit. If this is not possible (or a solution is not applicable for your use case), you should always add value to each commit message you write, so also if the PR has 10 commits all of them can be merged to the master without breaking the build. But if you really do not want to change your way of "when to create a commit" you can use your own commit message type and explain the usage in your documentation :D

GiteaMirror commented

2026-02-17 11:41:07 -06:00

@longility commented on GitHub (Apr 19, 2019):

@bcoe Yeah, I'm just wondering if anyone has their own conventions around this. I'm trying different things at the moment, and I haven't found one that I'm completely sold on just yet.

@longility commented on GitHub (Apr 19, 2019): @bcoe Yeah, I'm just wondering if anyone has their own conventions around this. I'm trying different things at the moment, and I haven't found one that I'm completely sold on just yet.

GiteaMirror commented

2026-02-17 11:41:08 -06:00

@angie commented on GitHub (Aug 14, 2020):

@longility did you ever come up with a nice convention? Facing the same problem on my current project.

@angie commented on GitHub (Aug 14, 2020): @longility did you ever come up with a nice convention? Facing the same problem on my current project.

GiteaMirror commented

2026-02-17 11:41:09 -06:00

@longility commented on GitHub (Aug 19, 2020):

@angie I did not. However, we may be able to brainstorm together. My first questions and thoughts would be...

Do you need to generate a changelog, derive a changelog, or the intent is to have meaningful and consistent commit messages?

I can see us using feat or similar on the commit that makes a feature publicly accessible, and wip when not publicly accessible in order to be able to filter out the impact of a commit.

@longility commented on GitHub (Aug 19, 2020): @angie I did not. However, we may be able to brainstorm together. My first questions and thoughts would be... Do you need to generate a changelog, derive a changelog, or the intent is to have meaningful and consistent commit messages? I can see us using `feat` or similar on the commit that makes a feature publicly accessible, and `wip` when not publicly accessible in order to be able to filter out the impact of a commit.

GiteaMirror commented

2026-02-17 11:41:10 -06:00

@angie commented on GitHub (Aug 24, 2020):

@longility my team uses a https://github.com/semantic-release plugin to generate a changelog, but meaningful and consistent commit messages are also a consideration.

For now, we extended the type-enum in our commitlint config to allow the wip type, as per your previous comment. 🤞

@angie commented on GitHub (Aug 24, 2020): @longility my team uses a https://github.com/semantic-release plugin to generate a changelog, but meaningful and consistent commit messages are also a consideration. For now, we extended the `type-enum` in our commitlint config to allow the `wip` type, as per your previous comment. 🤞

GiteaMirror commented

2026-02-17 11:41:11 -06:00

@damianopetrungaro commented on GitHub (Aug 24, 2020):

@angie do you merge "wip" commits into the master as well?

@damianopetrungaro commented on GitHub (Aug 24, 2020): @angie do you merge "wip" commits into the master as well?

GiteaMirror commented

2026-02-17 11:41:12 -06:00

@angie commented on GitHub (Aug 25, 2020):

@damianopetrungaro so far, yes! An example would be working on a new feature behind a feature flag. Any work on that feature would be prefixed wip until it became publicly accessible. @longility put that better than me.

@angie commented on GitHub (Aug 25, 2020): @damianopetrungaro so far, yes! An example would be working on a new feature behind a feature flag. Any work on that feature would be prefixed `wip` until it became publicly accessible. @longility put that better than me.

GiteaMirror commented

2026-02-17 11:41:12 -06:00

@damianopetrungaro commented on GitHub (Aug 25, 2020):

@angie got it, so my ""issue"" with that approach is that anyway the code you're merging is already on the master branch, and it's a full functional feature, protected by a features but still there.

I'd personally use WIP commit only when I am coding within a PR, before squashing/rebasing the commit history.

Given that this is the main reason the WIP type wouldn't make a lot of sense and I'll continue using a feat/chore type to add or remove features flags.

Example:

- feat(customer): add QR login // contains feature flag
- chore (customer): remove users from feature flag for QR login // add in the description who you removed
- feat(customer): remove feature flag for QR login

@damianopetrungaro commented on GitHub (Aug 25, 2020): @angie got it, so my ""issue"" with that approach is that anyway the code you're merging is already on the master branch, and it's a full functional feature, protected by a features but still there. I'd personally use WIP commit only when I am coding within a PR, before squashing/rebasing the commit history. Given that this is the main reason the WIP type wouldn't make a lot of sense and I'll continue using a feat/chore type to add or remove features flags. Example: ``` - feat(customer): add QR login // contains feature flag - chore (customer): remove users from feature flag for QR login // add in the description who you removed - feat(customer): remove feature flag for QR login ```

GiteaMirror commented

2026-02-17 11:41:14 -06:00

@angie commented on GitHub (Aug 25, 2020):

@damianopetrungaro for sure, I feel the same way as you about it for the most part and would prefer for things to work as your example illustrates. Recently we've had a couple of features to introduce which would have spawned really long-lived branches for a couple of reasons, even though we try to avoid that.

A WIP commit in the sense I'm describing is still passing all tests, linting, etc, but it's work on a feature which would otherwise spawn a branch with hundreds of commits over several weeks due to the makeup of the team, the size of the project, etc. The tradeoff we're making to avoid managing long-lived branches is a bunch of wip(whatever)-prefixed commits interlaced with everything else, because members of the team prefer that to having to maintain a feature branch. 🤷‍♀️

@angie commented on GitHub (Aug 25, 2020): @damianopetrungaro for sure, I feel the same way as you about it for the most part and would prefer for things to work as your example illustrates. Recently we've had a couple of features to introduce which would have spawned really long-lived branches for a couple of reasons, even though we try to avoid that. A WIP commit in the sense I'm describing is still passing all tests, linting, etc, but it's work on a feature which would otherwise spawn a branch with hundreds of commits over several weeks due to the makeup of the team, the size of the project, etc. The tradeoff we're making to avoid managing long-lived branches is a bunch of `wip(whatever)`-prefixed commits interlaced with everything else, because members of the team prefer that to having to maintain a feature branch. 🤷‍♀️

GiteaMirror commented

2026-02-17 11:41:14 -06:00

@damianopetrungaro commented on GitHub (Aug 25, 2020):

Every team has a different need, that's why we kept custom-types in place :)
I'd personally try to change the workflow to be more izipizi but I guess it's hard to change :D

@damianopetrungaro commented on GitHub (Aug 25, 2020): Every team has a different need, that's why we kept custom-types in place :) I'd personally try to change the workflow to be more izipizi but I guess it's hard to change :D

GiteaMirror referenced this issue

2026-02-17 11:56:54 -06:00

[PR #63] [CLOSED] FEAT: prescribe ALL-CAPS type when commit includes breaking change #272

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#63