Should fix for the new feature in current version use fix or ... ? #76

New Issue

GiteaMirror · 2026-02-17T11:42:59-06:00

GiteaMirror commented

2026-02-17 11:42:59 -06:00

Originally created by @mineschan on GitHub (Aug 29, 2019).

Hi guys, me and our team are trying to adopt this convention into our projects. And I come to this confusion and hope someone can give me some advises.

During an on-going sprint, new feature created and push to our repo with feat, which totally make sense and it will be included when we use tool to generate CHANGELOG. But then QA found a bug and ask developer the fix it right away.

So the develop would fix it and push to repo with fix, what bothering me is that, it would also be included when we generate the CHANGELOG afterwards, which make no sense.

What should we use for this kind of bug fixing? Appreciated for any suggestions.

Originally created by @mineschan on GitHub (Aug 29, 2019). Hi guys, me and our team are trying to adopt this convention into our projects. And I come to this confusion and hope someone can give me some advises. During an on-going sprint, new feature created and push to our repo with `feat`, which totally make sense and it will be included when we use tool to generate CHANGELOG. But then QA found a bug and ask developer the fix it right away. So the develop would fix it and push to repo with `fix`, what bothering me is that, it would also be included when we generate the CHANGELOG afterwards, which make no sense. What should we use for this kind of bug fixing? Appreciated for any suggestions.

GiteaMirror closed this issue

2026-02-17 11:42:59 -06:00

GiteaMirror commented

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

@damianopetrungaro commented on GitHub (Sep 5, 2019):

I think the right way is to rebase and squash the fix into the feature so that the PR has just 1 commit with the working feature.

If the feat has already been merged into the master, then you have no option rather than push a fix :D

Let me know if this makes send and reply to your doubt 😄

@damianopetrungaro commented on GitHub (Sep 5, 2019): I think the right way is to rebase and squash the fix into the feature so that the PR has just 1 commit with the working feature. If the `feat` has already been merged into the master, then you have no option rather than push a `fix` :D Let me know if this makes send and reply to your doubt 😄

GiteaMirror commented

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

@wesleytodd commented on GitHub (Sep 30, 2020):

If the feat has already been merged into the master, then you have no option rather than push a fix :D

Technically you can still rebase, fix, and force push. It depends on your team and how comfortable they all are with rebasing on top of a changed remote branch. I personally do this quite often, but it does require any teammates to know what to do, so it is probably best avoided by other git hygiene practices (like qa'ing on a feature or release branch).

@wesleytodd commented on GitHub (Sep 30, 2020): > If the feat has already been merged into the master, then you have no option rather than push a fix :D Technically you can still rebase, fix, and force push. It depends on your team and how comfortable they all are with rebasing on top of a changed remote branch. I personally do this quite often, but it does require any teammates to know what to do, so it is probably best avoided by other git hygiene practices (like qa'ing on a feature or release branch).

GiteaMirror commented

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

@damianopetrungaro commented on GitHub (Sep 30, 2020):

@wesleytodd force pushing sounds like "yolo, all the other ppl will need to rebase before merging their PR", I'd not love it tho 😂
Also IMHO if has been written in the main (aka master) then I'd love to keep it like that since it show a clear historical reason about when a bug was introduced/deployed/reverted/fixed (or similar).

@mineschan I'm gonna close this one, if you have any other question regarding this, feel free to reopen it! :D

@damianopetrungaro commented on GitHub (Sep 30, 2020): @wesleytodd force pushing sounds like "yolo, all the other ppl will need to rebase before merging their PR", I'd not love it tho 😂 Also IMHO if has been written in the main (aka master) then I'd love to keep it like that since it show a clear historical reason about when a bug was introduced/deployed/reverted/fixed (or similar). @mineschan I'm gonna close this one, if you have any other question regarding this, feel free to reopen it! :D

GiteaMirror commented

2026-02-17 11:43:03 -06:00

@wesleytodd commented on GitHub (Sep 30, 2020):

Yep, just depends on the project and team. I rebase basically every PR (if I am the author or merger) anyway, so doesn't matter much to me. Still, I agree usually you would want to avoid it, and there is no reason not to push the following fix commit.

Agreed closing is the best for this since it is pretty well sorted out and isn't really a change to the spec.

@wesleytodd commented on GitHub (Sep 30, 2020): Yep, just depends on the project and team. I rebase basically every PR (if I am the author or merger) anyway, so doesn't matter much to me. Still, I agree usually you would want to avoid it, and there is no reason *not* to push the following `fix` commit. Agreed closing is the best for this since it is pretty well sorted out and isn't really a change to the spec.

GiteaMirror referenced this issue

2026-02-17 11:57:15 -06:00

[PR #86] [MERGED] Remove 'NOT recommended' wording from the 'Other types' paragraph discussing breaking changes #280

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#76

Should fix for the new feature in current version use fix or ... ? #76

Should `fix` for the new feature in current version use `fix` or ... ? #76