在gitflow模型中创建修补程序分支或功能分支

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).

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.