问题将Git Feature分支合并到“Beta”分支（在它已经合并到“Develop”分支之后）

Question

We have a standard web project and maintain 3 core branches for this project: Master, Beta, and Develop. Here is a summary of the process/workflow that we use:

(1) A new feature/update is requested so we create a new Feature branch.

(2) A commit is made for the new Feature branch and the Feature branch is merged into the 'Develop' branch; the 'Develop' branch is then published to a testing environment to be tested.

(3) Once the new feature is tested/approved, a new pull request is made in the same Feature branch; this new pull request is meant to be merged into the 'Beta' branch.

The 'Beta' branch has all of our "ready-to-go-live" features: in fact, we publish the 'Beta' branch directly to the production environment and when that is ready we immediately merge the 'Beta' branch to the 'Master' branch....by doing this, the 'Master' branch is always a copy of the code that is on the production environment.

The problem: in step 3 above, when we try to merge the new Feature branch into the 'Beta' branch, the pull request includes ALL new commits that have been merged into the 'Develop' branch.

Example: 5 feature branches are individually merged to the 'Develop' branch (branches are labeled 1, 2, 3, 4, and 5). All 5 are tested, but there are bugs with the first 4. So branch "5" is approved and we try to create a pull request for that Feature branch and merge it to 'Beta'....but when we do that, the pull request includes all 5 feature branches....not just the commit for branch "5".

We MUST be doing something wrong! What can we do to fix our process/workflow?

Answer 1

(3) Once the new feature is tested/approved, a new pull request is made in the same Feature branch; this new pull request is meant to be merged into the 'Beta' branch.

The 'Beta' branch has all of our "ready-to-go-live" features: in fact, we publish the 'Beta' branch directly to the production environment and when that is ready we immediately merge the 'Beta' branch to the 'Master' branch....by doing this, the 'Master' branch is always a copy of the code that is on the production environment.

The problem: in step 3 above, when we try to merge the new Feature branch into the 'Beta' branch, the pull request includes ALL new commits that have been merged into the 'Develop' branch.

No, that does not make sense. If that happens you have omitted important information such as:

• Each new feature branch is branched off of another branch. Which one, development? Then it is clear that whatever development commits are in the history of a newly created feature, will also be merged into the beta branch. Git history is a directed acyclic graph, each commit pointing to one (normal commit) or multiple (merge commit) parent commits.
• In order to make features merge cleanly into develop, maybe the feature branches are rebased onto development regularly or maybe the feature branches get refreshed by merging in the latest develop, both of which makes much sense and I advocate it. But in this case also their history contains all the history of develop at the time of merging/rebasing.

In each of these cases your workflow is fundamentally broken and cannot work with regard to your idea of a beta branch. So if you want to avoid cherry-picking (bad! bad! bad!) how can you achieve what you want to do? There are some basic options:

1. Feature toggles: ugly. I would stay away from it whenever possible. The best way to inactivate a feature in any branch is not having the corresponding commits on that branch in the first place.
2. Work cleanly: good. Refrain from merging back untested/unaccepted features to develop. Only merge them when they are done (as in "definition of done") and accepted by the client. Make sure you set up an environment enabling your clients to directly test on feature branches instead of mashing it all up onto a beta branch. This way whatever gets on development is inherently ready for production and you do not need the beta branch anymore. Unfinished work is never to be merged into a higher-level branch. This is what GitFlow is all about and it works. Even if you do not use GitFlow in its full glory but just master, develop and feature branches, the validity of my statements holds. I have worked like this in many projects and it works beautifully. Besides, if you think you need another branch to integrate features onto for future releases, create a new "next_release" or "future" branch for them and merge them to that branch, not onto develop. Then regularly refresh future from develop because you also want your features from the current release in the future release, but not vice versa. I hardly believe that this additional step will be necessary though.

Answer 2

That's the way git works. You'll need to create separate branches for each feature.

Answer 3

Once you merge a branch with another, the merging branch commits get commited on the home branch.

What you probably want to be doing is not even work on the development branch for development, but rather branch out of it for each feature (serialize the features, of course) which are then separately checked for bugs before merging packages of many feature branches into the development branch.

To get rid of bugs that got into the development branch anyway you will need to get the code working on the feature branch and then merge that OR revert the changes by reverting the feature branch using git revert and then merging the branch again (effectively reverting only the commits that it introduced to the development branch .

Reverting on the development branch (or any of the bigger branches in your hierarchy) is generally ill advised in the industry, except when you merge just a single feature... as different commits can establish dependencies between themselves and reverting can cause more harm than it solves.

To get a better hang on reverting read this guide by atlassian or the available documentation .

Answer 4

You're correct, our workflow differs from the traditional GitFlow. Feature branches are merged into EITHER develop or beta , entirely independently.

Once the new feature is tested/approved, a new pull request is made in the same Feature branch

        f2--f2--f2   (f2)
       /          \
d--d--d--D1-------D2 (develop)
\       /
 f1---f1

a bunch of unwanted/unrelated feature branch commits are merged into "beta" as well

Strange: that would be as if f2 was on the D2 merge commit (which has f2 but also f1).

For testing, could you try in command-line to cherry-pick the exact commits you want , then merge them with --squash .

git checkout -b tmp develop
git cherry-pick  $(git merge-base develop f2) f2
git checkout beta
git merge --squash tmp

That way, you can validate you only get the exact f2 merged branch you want in beta, and not all the other features.
Once that is validated, we can work on doing the same from a GUI (like for instance SourceTree)

Answer 5

You say that merging feature 5 into beta will bring features 1-4 into beta as well. If so, the commits for features 1-4 are definitely in the feature 5 branch. There are 3 ways that could happen:

1. Feature 5 was branched out from develop after features 1-4 were merged into develop.

2. Develop was merged into feature 5 (upmerge) after features 1-4 were merged into develop.

3. Features 1-4 were merged directly into feature 5.

Beware that a branch contains not just the commits made directly to the branch, but also all commits from the beginning of the repo up to the branching point, and any commits in branches merged into the branch.

BTW, the 3 points above hold even if you change 'merge' to 'rebase', or 'develop' to any other branch.

Answer 6

I would be doing the follow steps.

• Feature branches created from develop.
• Once feature are done merge them to develop branch.
• When time for testing comes I will create a test branch and do the tests there.I will fix any bug which comes in testing there itself.
• Once my test are all successful I merge the branch to both master and develop.
• I would then release my code from master to Beta environment.

I will keep in mind the following things .

• If a feature is not needed for particular release I would not merge that feature to develo branch.
• If I could not solve any bugs while testing I would not be releasing that code,hence as in the question I would have solved all the bugs and would be releasing the whole code.