Git 分支策略 - 合并时丢失更改

Question

We've got a branching strategy with develop, release, and master branches. Features/bugs branch off of release. When complete, they merge into develop for QA testing. Once QA passes, they merge (directly from the feature/bug branch) into release for release regression testing. Release merges to master after final regression testing. Hotfixes branch off master, merge back into master.

With all that said, we are sometimes losing changes in release and QA when merging branches in. Developers are merging from release into their branches prior to merging into QA and release, but never merging in from QA.

Are there any conceptual issues with this strategy? Any potential reasons why we may be losing those changes?

Answer 1

Your strategy is sound, and has a name: gitworkflow , which allows to merge only the feature branch you want/need in QA or release (instead of merging everything from QA to release)

But that does not account for any "lost changes": that would be caused by merge conflict resolution which somehow keep one change and override another concurrent change.

Developers are merging from release into their branches

That is the only flaw I can see. No merge is ever made from release or master . Those are branches you merge to , not from .

The best practice is to rebase a dev branch on top of their intended merge target ( QA or release ), and then merge them.

Answer 2

We've got a branching strategy with develop, release, and master branches.

That sounds a bit like Gitflow . But the rest of your description does not. So I am assuming you are using something else on purpose and did not just misunderstand Gitflow. That is absolutely fine, but IMO your concept is flawed for some reasons. I am saying that because you directly asked:

Are there any conceptual issues with this strategy?

So yes, there are.

Features/bugs branch off of release. When complete, they merge into develop for QA testing.

That sounds a bit weird. Features should branch off of develop, QA tested directly in their own branches and only merged back into develop after QA has passed, where subsequently you can do additional integration testing.

On a side note: In projects where I work as a coach, we usually have a rule that merges from subordinate (less stable) to higher-ranking (more stable) branches always have to be fast-forwards. Ie, if during feature development some other features happen to have been QA-tested and merged back into develop earlier than the currently tested ones, the feature branch must be refreshed from development, re-tested as much as necessary and only then fast-forwarded back into develop. That means, both feature QA testing and integration testing are done in the feature branch. A feature or bugfix is only merged back into development after it is clear that it does not only work in isolation but also integrated with all other work which was already accepted into development before. I call that the "no surprises" rule. The situation "oh, on the feature branch it was working, why does it not work on the development branch?" simply cannot occur and no additional post-merge integration testing is even necessary, because it was a fast-forward.

So this directly contradicts what VonC said in his answer:

No merge is ever made from release or master. Those are branches you merge to, not from.

I could not disagree more. Subordinate branches should be refreshed from higher-ranking ones regularly, because by definition on higher-ranking ones there is always work that was accepted to be merged (or fast-forwarded) there before, ie it is inevitable that you have to integrate with them. Merge conflicts or post-merge integration problems ought to be fixed in the feature or bugfix branch before accepting and merging them back into the higher-ranking branch. IMO it is an absolute no-no to mess up a higher-ranking branch with newly introduced instability and then clean up the mess there.

Once QA passes, they merge (directly from the feature/bug branch) into release for release regression testing.

Before, you said that you do integration testing on develop, ie you resolve merge conflicts there which might be completely different from the ones (if any) you will have when merging the feature back into release. Moreover, you are merging back something other than was integration-tested. So even if there are no conflicts and everything goes super smoothly, what you are merging and what you have been testing is not the same. That is very dangerous IMO. In your setup, the release branch contains other things than develop, and you seem to abuse - sorry for the opinionated term, but I indeed hold that opinion - develop as some kind of conflict-resolving and integration-testing sandbox, only not to merge back to the release branch from there later.

You have no clear hierarchy of branches like Gitflow or a simple feature branch workflow do. I think this is dangerous and calling for trouble.

Release merges to master after final regression testing.

See? That is another side effect: You QA-test the feature, then integration-test develop, merge something else, then have to re-test ("final regression testing") again, which should not even be necessary with a good, hierarchical branching and merging strategy.

Hotfixes branch off master, merge back into master.

I want to say more about that, but in this case it is not the source of the problem, because at least this is hierarchical. You merge back to where you branched off of. As long as you regularly refresh subordinate branches from master in order to also have the hotfixes there, OK, but only then.