git GitFlow：安全地将开发更改合并到功能分支

GitFlow: safely merge develop changes to a feature branch

提问by Ilija

Recently I started working on a big features, so I created a new feature/xyzbranch. Problem is that this feature is big, so it will take me ~3 months to complete it. I would like to safely merge progress that has been made in developto my feature branch, without worrying that changes from developbranch will override updates that I already made in my feature branch. My previous attempt to merge developto feature/xyzended up in some changes that I already made in the new feature being reverted.

最近我开始研究一个大特性，所以我创建了一个新feature/xyz分支。问题是这个功能很大，所以我需要~3个月才能完成。我想安全地将已完成的进度合并develop到我的功能分支中，而不必担心来自develop分支的更改会覆盖我已经在功能分支中进行的更新。我以前试图合并develop到feature/xyz一些变化，我已经在新功能作出最终被还原。

What would be the command to achieve this? Thanks

实现这一目标的命令是什么？谢谢

回答by mockinterface

The only safety is in learned, discerning and frequent merges.

唯一的安全在于博学、敏锐和频繁的合并。

Only you understand how the code on developand feature/xyzaligns, no one else. It is only you who can merge the two flows correctly in a discerning way. Even with the default merging strategies, which are far less dangerous than -S oursor -X theirsyou still always have to review the result.

只有您了解代码如何打开develop和feature/xyz对齐，其他人不知道。只有你才能以一种有洞察力的方式正确地融合这两种流动。即使使用默认的合并策略，其危险性远低于-S ours否则-X theirs您仍然必须始终查看结果。

You may need some help of course, and git will offer some. For example, you can use git recorded resolutions - rerereto help with making the same correct merge decision after you made one initially.

当然，您可能需要一些帮助，而 git 会提供一些帮助。例如，您可以使用 git 记录的分辨率 - rerere来帮助您在最初做出合并决定后做出相同的正确合并决定。

A fairly common, and relatively simple model, using the names you've supplied for the branches, could work for you like this,

一个相当常见且相对简单的模型，使用您为分支提供的名称，可以像这样为您工作，

• developis the branch where the main thrust of development occurs
• xyzis the branch where you develop the feature xyz
• xyz_stageis the branch where you merge the developand the xyzcode, keeping that branch stable in line with the respective stable points of developand xyz. This is also the branch that you'd eventually merge back into develop when you are ready to release feature xyz or part of thereof.

• develop是发展的主要推动力发生的分支
• xyz是您开发功能 xyz 的分支
• xyz_stage是你合并分支develop和xyz代码，保持该分支稳定符合各自的稳定点develop和xyz。当您准备发布功能 xyz 或其中的一部分时，这也是您最终合并回 develop 的分支。

The above assumes that not only you merge xyzinto xyz_stagebut that you also merge developinto xyz_stagefrom time to time and make sure that the portions of xyzso far released to xyz_stagework and pass the relevant tests in conjunction with the code from develop.

以上假设你不仅合并xyz到xyz_stage，但你也合并develop成xyz_stage不时和确保的部分xyz至今发布xyz_stage工作，并与从代码通过相关测试结合develop。

Nevertheless, you still have to choose how do you make the xyzbranch, where you work on the feature, aware of the progress on develop.

尽管如此，您仍然必须选择如何创建xyz分支，在何处处理功能，了解开发的进度。

The cleanest option is - don't make it aware. That's why you have xyz_stagewhere the two development flows come together. This approach is feasible and sane as long as the development of xyzis not prolonged.

最干净的选择是 - 不要让它意识到。这就是为什么您xyz_stage将两个开发流程结合在一起的原因。只要xyz不延长开发时间，这种方法是可行且理智的。

The second option is to merge xyz_stageback into xyzwhen you are happy with the staging branch. That way you will have stable point that you can continue and develop the xyzfeature on top.

第二种选择是在您对暂存分支感到满意时合并xyz_stage回xyz。这样你就有了稳定点，你可以继续并xyz在上面开发功能。

Here's a simple illustration of the process, with comments:

这是该过程的简单说明，并附有注释：

回答by Chris

Use git merge -s recursive -X ours. This will cause conflicts in the two branches to always resolve using the version in the checked out directory (feature/xyzin this case).

使用git merge -s recursive -X ours. 这将导致两个分支中的冲突始终使用检出目录中的版本（feature/xyz在本例中）来解决。

Important: contrary to your title, this strategy is not necessarily "safe": the modifications from developmight conflict the the ones in feature/xyz. As always, make sure to properly test the merged changes.

重要提示：与您的标题相反，此策略不一定“安全”： 中的修改develop可能与feature/xyz. 与往常一样，请确保正确测试合并的更改。

回答by axl

In my experience, the only "safe" solution is to always manually inspect and test the result of any merge. --no-commit will stage the merge and let you inspect it before committing, or you can reset/amend, whatever feels more practical. Getting a three-way-merge tool can be very helpful. There are just too many ways things can break without there being merge conflicts, that relying on automatic merging is bound to get you into trouble. If you have 100% test coverage, sure, you can be a bit more relaxed, but how many projects can really claim that? ;-)

根据我的经验，唯一“安全”的解决方案是始终手动检查和测试任何合并的结果。--no-commit 将暂存合并并让您在提交之前检查它，或者您可以重置/修改，任何感觉更实用。获得三向合并工具可能会很有帮助。在没有合并冲突的情况下，有太多方法可以破坏事情，依靠自动合并必然会让您陷入困境。如果您有 100% 的测试覆盖率，当然，您可以轻松一点，但是有多少项目可以真正做到这一点？;-)