git工作流：一次合并和修复冲突

我们有一个包含三个主要分支的简单工作流

staging

即测试环境

master

即生产环境

dev/XXX

其中XXX是票号

• 客户端记录票据
• 我们创建了一个分支，例如

  dev/2332

• 我们工作+承诺+推动
• 准备就绪后，我们将工作合并到

  暂存中

• 客户批准了

  staging

• 我们将工作合并到

  master

  中，并在生产中部署工单

问题是：

如果多个开发人员正在各自的

dev/XXX

分支上工作； 当它们合并到

暂存中时，有时会产生冲突。他们在登台和推送时解决这些冲突

问题是，当客户批准这些特定票据，我们将工作合并到
主文件中时，我们必须再次修复冲突

重要：


由于未经批准的票证，我们无法将暂存合并到master中
默认情况下，所有分支都是从最新的主分支创建的
正在同时开发多个票证，但在获得批准后部署
只有在工作已经批准并部署的情况下，才可以从主服务器重新调整以避免冲突
由于未经批准的票证，从暂存重新定基不是一个选项

关于如何解决这个问题有什么想法吗？我们的工作流程有缺陷吗？我们是不是错过了一些git黑客

基本上，我不希望团队重复同样的事情两次

谢谢
您需要让
主机
和
登台
尽可能靠近彼此。您可以尝试用git本身处理
pu
分支的方式来处理它。也就是说，当一项新任务完成时，分支将被删除，并从
master
重新创建，所有待审批的功能将合并到中。这样做的好处是，分支不会出现分歧，而且不存在不合并被拒绝的特性的问题。缺点是你不能把任何工作建立在它的基础上，但你无论如何都不能

当出现冲突时，您可以调整开发分支以干净地合并，并再次运行“八达通”合并（与两个以上的父级合并）创建
staging
，或者等待任何依赖项或冲突功能得到批准，然后再尝试转移依赖项

在任何情况下，功能分支都应该在尝试阶段化之前重新基于（或与）最新的
master
。它们是在创建时由母版制作的，因此在以后的母版上重新设置它们就像它们是在以后启动并更快开发的，这显然是正确的。
请看。你应该得到我关于这个主题的帖子。我在这里还回答了一个关于
的问题，因为您的
staging
分支机构累积未经批准的更改的方式，因此在
staging
和
master
上出现的合并冲突并不总是相同的。所以我不知道如何避免合并两次。显而易见的解决方案（尽管您可能有理由认为它不起作用）是摆脱
暂存
，并测试/验证
dev/XXX
分支内的更改，该分支已从主分支重新设置为基址。在我的组织中，暂存是一个服务器，它在生产之前获取最新的
主文件
，以进行最后一次健全性检查。因此，不允许出现分歧…继续。。。如果你仔细想想，以你目前的方式测试你的改变是不理想的。如果来自
dev/123
的更改仅在
dev/456
（挂在
staging
上的未经批准的更改）也被应用时才起作用，该怎么办？然后，将
dev/123
合并到
master
将导致在脏
staging
分支中无法检测到的中断。该分支基于master。这意味着它可以（也应该）在开发过程中的任何时候，特别是在尝试合并到暂存之前，在以后的主控上重新设置基础。@grossvogel感谢您的回复。最终，舞台赶上了大师。然而，在处理dev/123时——因为它是在自己的分支中开发和测试的——在合并到staging之前发现了对dev/456的依赖关系。@JanHudec是的，我们现在就是这么做的，但有时我们必须在重新基础期间处理冲突。我们合并到Master时总是快速前进谢谢
git Reerre
正是我想要的——很失望他没有把它写进他的书中