用另一个分支的更改覆盖分支

Question

各位git用户您好！

我遇到以下问题，我不知道避免它的最佳和正确方法是什么。 所以在这里我将解释：

我正在与 2 个不同的分支机构合作：

• master --> 生产

• dev --> 开发

我目前使用的工作流程如下：

1. 在dev分支上进行更改
2. 更改经过测试和批准
3. Checkout master并合并dev以包含新的更改

到目前为止没有什么疯狂的，对吧？

现在，几周前出现了以下场景：

1. 在dev分支上进行更改

2. 更改经过测试和批准

3. Checkout master并合并dev以包含新的更改

4. 有人意识到这些更改的一部分不应该在master （生产）中

5. 在master分支中，我们评论了这些更改，以便在master中不启用这些更改

现在的情况：

• 所有更改都在dev中

• 所有更改都在master中，但其中一部分已禁用

• 到目前为止，一切都很好

几天后，发生了以下事情：

1. 向dev添加了一些更改

2. 更改已经过测试和批准

3. 检查master并合并dev以包括最近的新更改以及现在在master中注释的更改的一部分。

4. 结果，所有内容都包含在master中，但已评论的更改仍在master中评论。

一开始，我有点期待master被dev版本覆盖，但后来我意识到这没有多大意义，因为合并实际上是将两个分支的更改放在一起，所以结果是绝对有意义的。 但是，这不是我需要的。

最好的解决方案是什么？ 我在考虑以下选项：

1. 绝对禁止在master分支中进行更改。 所以任何更改（比如注释部分代码）都应该首先在dev中完成，然后 go 到master 。

2. 合并到master时使用参数表示忽略当前分支中的所有更改，只获取来自dev分支的所有内容。 那太棒了，显然我不知道如何在 git 中做到这一点。

无论如何，您的意见将不胜感激。

谢谢！

Answer 1

这是你应该做的

在对master进行更改后，您应该立即将master合并到dev （一种修补程序，这很好）。

然后在dev上你应该恢复提交（ git revert commit-id ），它在master中注释掉了东西。

然后当你继续将dev再次合并到master时，一切都会好起来的。

现在事情已经更进一步了，你可以：

1. [最佳方法] 尝试上述步骤； 如果在dev中所做的更改不够深入和/或没有触及与commit相同的地方，那么一切都会是正确的； 要么

2. 在master分支 go 上还原（ git revert ）提交。

Answer 2

请在 GitFlow 上阅读Vincent Driessen 的原始博客。

这里缺少的是你直接提交给master 。 永远不要那样做：:)

您有几个选项，具体取决于您的具体情况，但如果您遵循 GitFlow，答案如下：

1. 当准备好发布时，创建一个release_xxx分支，它本质上是新版本的发布候选者。
2. 在与其他回购/代码等的集成和系统测试期间使用发布分支。
3. 如果需要更改，请将其release ，然后将该更改也合并到dev 。
4. 当release完全测试后，将其合并到 master 中，结束它。

如果您通常不需要延长发布分支的时间，则可以创建一个hotfix分支，该分支在测试后将合并到master和dev 。 Hotfix 分支通常用于解决已经发布到生产环境中的生产问题——它就像一个合并到dev的功能分支，除了打算直接合并回master （除了dev之外，所以所有开发分支也会得到更改）。

这使您可以继续在dev中进行其他并行开发，而不必将dev中的新内容推送到master ，只留下修复所需的更改发生在release或hotfix分支中，并且您可以单独将其推送回dev以确保它与任何并行工作相结合。

图片来源：文森特·德里森

---

解决当前问题

您应该将master反向合并到dev ，解决所有差异（即添加或删除评论等），然后合并回master 。 如果你只是想清理，你可以这样做并直接推送到 master，但最好有一个 PR 和dev中同行的审查，以提供可追溯性并清楚地显示 git 历史中做了什么。