Git 工作流程：合并和解决冲突

Question

我们有一个简单的工作流程，包括三个主要分支：

staging 即测试环境

master 即生产环境

dev/XXX 其中XXX是票号

• 客户提交问题票
• 我们创建一个分支，例如dev/2332
• 我们进行工作+提交+推送
• 当准备好时，我们将工作合并到staging中
• 客户在staging上批准工作
• 我们将工作合并到master中，并在生产环境部署该票

问题：

如果多个开发人员正在各自的dev/XXX分支上工作；当他们合并到staging时，有时会产生冲突。他们在staging上解决这些冲突并推送。

问题在于，当客户批准这些特定的票并且我们将工作合并到master中时，我们必须再次解决冲突。

重要提示：

• 由于未经批准的票证，我们无法将暂存区合并到主分支
• 默认情况下，所有分支都是从最新的主分支创建的
• 多个票证同时开发，但在批准后部署
• 如果已经获得批准并已部署工作，则从主分支进行变基以避免冲突仅是一种选择
• 由于未经批准的票证，从暂存区进行变基不是一个选项

有没有解决此问题的想法？我们的工作流程是否有缺陷？我们是否缺少一些 Git 小技巧？

基本上，我不希望团队重复相同的工作

谢谢

- hbt

---

由于您的“staging”分支累积了未经批准的更改，因此在“staging”和“master”上出现的合并冲突并不总是相同的。因此，我不知道您如何避免必须进行两次合并。显而易见的解决方法（尽管您可能有理由认为它行不通）是摆脱“staging”，并在从主分支派生的“dev/XXX”分支中测试/验证更改，这样可以重新设置基础。在我的组织中，“staging”是一个服务器，在生产之前获取最新的“master”进行最后的检查。因此，不允许发散。 - grossvogel

如果你仔细想一下，以目前的方式测试你的更改并不理想。如果dev/123的更改只有在应用了staging上未经批准的更改dev/456时才能生效呢？那么将dev/123合并到master中将会导致一个错误，在你肮脏的staging分支中永远无法检测到。 - grossvogel

该分支基于主分支。这意味着在开发过程中，特别是在尝试合并到暂存区之前，它可以（并且应该）在后续的主分支上进行变基。 - Jan Hudec

@grossvogel 谢谢您的回复。最终，暂存区会追上主分支。但是，在处理dev/123时——因为它是在自己的分支中开发和测试的——在合并到暂存区之前发现了对dev/456的依赖。 - hbt

@JanHudec 是的，那是我们现在所做的，但有时我们必须在rebase期间处理冲突。当合并到主分支时，我们总是使用快进方式。 - hbt

@hbt：但是在合并到**staging**之前进行变基可以减少以后这种冲突的数量。现在和以后总会有一些冲突；关键是尽量减少它们的数量。 - Jan Hudec

Answer 1

看一下每个功能分支一个分支。你应该能够找到我关于这个主题的文章。我还在这里回答了一个关于共享rerere缓存的问题。

- Adam Dymitruk

---

谢谢。git rerere正是我正在寻找的——很失望他没有在他的书中包含它。http://git-scm.com/2010/03/08/rerere.html - hbt

Answer 2

你需要尽可能让master和staging保持接近。你可以尝试像git自己的pu分支一样处理它。也就是说，当一个新任务完成时，该分支被删除，从master重新创建，并合并所有待批准的功能。这样做的优点是分支不会分叉，没有未合并的被拒绝的功能问题。缺点是你不能在其上进行任何工作，但你也不需要。

当冲突出现时，你可以调整开发分支以使其干净地合并，并运行“章鱼”合并（与两个以上的父级合并），再次创建staging，或者等待任何依赖项或冲突的功能被批准后再尝试对其进行分阶段。

无论如何，在尝试对其进行分阶段之前，特性分支应该在最新的master上进行变基（或合并）。它们是从master创建的，所以将它们变基到更晚的master上就像它们是后来开始并快速开发的，这显然是正确的。

- Jan Hudec