在我们的Git工作流程中，如何减少合并冗余以确保master是所有根的根? [英] How to reduce the merge-redundancy, which is used to make sure master is the root of all, in our Git workflow?

问题描述

我们使用"Git工作流程"由 Vincent Driessen 负责，这是2个长期存在的分支机构master/dev.我们认为我们需要2个长期存在的分支，而不是 github flow 中的一个分支，因为我们从事企业(2B)业务.客户比我们的最新功能更喜欢稳定的产品.

We use the "Git workflow" by Vincent Driessen, 2 long lived branches master/dev. We believe we need 2 long lived branches instead of one in github flow because we do enterprise (2B) business. Our customer prefer a stable product over our latest features.

在每个发行版(将开发人员合并到母版)之后，我们的测试团队将确定在下一个发行版中需要修复的几个错误，然后在dev分支中对其进行修复.我们开发的新功能也已合并到dev分支中.合并到dev中后，bug-fix分支和feature分支将被删除.

After each release (merge dev into master) our test team will identify a couple of bugs we need to fix in the next release, we then fix them in dev branch. The new features we develop are merged into dev branch too. The bug-fix branch and feature branch will be deleted after they are merge in to dev.

但是突然之间，客户支持团队接到了客户的一些愤怒的电话，并告诉我们我们需要特定的错误修复/功能才能快速出现在产品中.这种情况打断了我们正常的工作流程，并引入了我要问的问题.

But suddenly the customer support team gets some angry call from the customer and tell us that we need a specific bug-fix/feature to be in product quickly. This situation interrupts our normal workflow and introduces the question I am asking.

由于代码更改我们的客户需求已经在dev分支中，因此我们将需要的提交樱桃挑选到master中(即使我们完全了解

Because the code changes our customer needs are already in dev branch, we cherry-pick the wanted commits into master (even though we are full aware of the problem that cherry-pick will introduce). Cherry-pick seems the only option here.

但是我们总是要确保 master分支是所有其他分支的基础，我们总是在此之后将master分支合并到dev分支.合并通常不会在dev分支中引入代码更改，而只是向所有人显示分支树，即master是根.

But we always want to make sure the master branch is the base for all the other branches, we always do a merge from master to dev branch after that. The merge normally won't introduce code change in dev branch but just to show the branch tree to everyone that master is the root.

我知道我可以在master上重新开发dev分支，以避免合并.但是由于一些原因，重新设置也不理想(我在这里没有列出它们是为了避免跟踪我的问题)

I know I can rebase dev branch on master to avoid that merge. But rebase is not ideal either for couples of reasons (I didn't list them here to avoid sidetracking my question)

那么还有其他方法可以确保master是所有人的根，并且还可以避免重复/空合并?

So is there other way to make sure master is the root of all and also avoid duplicated/empty merge?

推荐答案

在整个分支中有时甚至令人满意地正确应用提交的完整方法(我敢说是规范的)是

The full-fat (I dare say canonical) way to excruciatingly-and-sometimes-gratifyingly-properly apply a commit across branches is

git checkout -b fixbug26535 $(git merge-base all active tips with the bug)
git cherry-pick the bug fix
git checkout where-the-fix-came-from
git merge -s ours bugfix26535

(因此，如果您拥有 master ， dev1 和 dev2 ，而错误修复程序很方便地出现在dev1提示中，

(So if you've got master, dev1 and dev2 and the bugfix is conveniently at the dev1 tip,

git checkout -b fixbug26535 $(git merge-base master dev1 dev2)
git cherry-pick dev1
git checkout dev1
git merge -s ours bugfix26535

)

，现在您有了一个不错的可合并bugfix分支，该分支不会进行不必要的更改，也不会在可能合并到的任何提示中造成不必要的冲突.您可以在闲暇时将其合并到 master 和 dev2 .

and now you've got a nice mergeable bugfix branch that won't carry unwanted changes to or create unnecessary conflict in any of the tips it might get merged to. You can merge that to master and dev2 at your leisure.

但是因为我们总是要确保master分支是所有其他分支的基础，所以我们总是在此之后将master分支合并到dev分支.

But because we always want to make sure the master branch is the base for all the other branches, we always do a merger from master to dev branch after that.

您可以在将错误修正合并到母版之前或之后执行此操作，因为已经记录了其更改的正确祖先.

You can do that before or after merging the bugfix to master, because the proper ancestry for its changes is already recorded.

要徘徊在录音上，请在引入错误的提交的基础上进行错误修正，然后从上方合并到合并基础，以一次完成所有常见更新.结果历史记录的Ascii图会比较混乱，但是结构将绝对记录发生的一切和原因.

To wander towards persnickety about your recording, base your bugfix on the commit that introduced the bug, then merge to the merge base from above to get all the common updates done at once. Ascii graphs of the resulting history will be messy, but the structure will record absolutely everything about what happened and why.

这篇关于在我们的Git工作流程中，如何减少合并冗余以确保master是所有根的根?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！