Create a hotfix branch or a feature branch in gitflow model

Question

I'm using this model in my team:

Today my project stats is following:

• The stable version is running in production using master branch
• We developed new functionalities that need to be tested before production, so we have a release branch be testing under SIT Environment. This new functionalities just can be merged with master after all tests in SIT Environment.

The problem: The Product Owner requested a new field in a Table in Production. So the team suggest two solutions:

• Create a hotfix branch from master , add the new field and deploy to a Test Environment. This hotfix can wait months until merge with master, because after test pass we need wait the Product Owner say that can go to production because this field depends on another system changes.

• Create a feature branch from develop and add this new field and deploy to a Test Environment. I think this is worst solution because i have things in develop that can't be merged to master, so i will need a cherry-pick to pick-up only desired changed from release to master. Remember that team is validating others functionalities in SIT Environment (release branch).

Countertype

I'm really impressed with your workflow, it is really systematic. Coming to the current issue, I feel your process still holds good for this situation as well. If your Production is on 0.2, consider creating a feature branch(say, new_table) from first Yellow Dot and merge all hot fixes that get deployed to Production. In this way, when new_table is ready to go to Production, is will be very smooth. If there are more releases before merging New Table, new_table will integrate those changes or migrate new_table to another feature branch created from latest release. – Charlesettacharleston

If I create feature from develop branch I will got functionalities that don't should go to production in this new feature branch. Remember that I can't send develop to production yet – Countertype

Yes, that is the reason I suggested to create new_table from first Yellow Dot that is same as the master branch commit. You won't get any development changes. – Charlesettacharleston

Ok but after finished I will need merge feature to develop and I will got in same problem. – Countertype

That is unavoidable, and it is the responsibility of the developer(s) of new_table not SCM. Dev team can have another branch that stays up-to-date with develop branch to avoid a big merge conflict at the end. – Charlesettacharleston

Unhappy the big problem is not merge but the functionalities that can't go to master. How can I send only this change without send all other features inside a develop or release branch? – Countertype

If you create new_table from First Yellow Dot in your diagram and merge latest Red Dot or Green Dot as I suggested, new_table branch will have only release code + New Table feature. – Charlesettacharleston

Release code can't be merged with master too, because we are testing yet – Countertype

Answer 1

If I create feature from develop branch I will got functionalities that don't should go to production in this new feature branch. Remember that I can't send develop to production yet

Unhappy the big problem is not merge but the functionalities that can't go to master. How can I send only this change without send all other features inside a develop or release branch?

That means gitflow is not the workflow for you.
Switch to the gitworkflow (one word, illustrated here).
See more at rocketraman/gitworkflow.

That kind of workflow (where you don't merge dev to master, but where you merge only feature branch to dev, then if selected, to master, in order to be able to drop easily feature branches not ready for the next release) is implemented in the Git repo itself.

^{(source: Gitworkflow: A Task-Oriented Primer)}

You have:

• master is the branch ready to be deployed into production at any time: the next release, with a selected set of feature branches merged in master.
• dev (or integration branch, or 'next') is the one where the feature branch selected for the next release are tested together
• maintenance (or hot-fix) branch is the one for the current release evolution/bug fixes, with possible merges back to dev and or master

Note: in that distributed workflow, you can commit whenever you want and push to a personal branch some WIP (Work In Progress) without issue: you will be able to reorganize (git rebase) your commits before making them part of a feature branch.

Slicer

I think about a more easy solution. Create a hotfix branch from master. What do you think? – Countertype

@RonaldoLanhellas As long as you stay in a model of each branch is supposed to be merged in the next (feature to dev, dev, to release), you will have issue with "sending only this change without send all other features inside a develop or release branch" – Slicer

Yeah, but my ideia is create a hotfix from master, after finished and tested, merge to master. – Countertype