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

Question

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

staging，即测试环境

master，即生产环境

dev/XXX其中XXX是门票号

• 客户登录门票
• 我们创建了一个分支，例如dev/2332
• 我们工作+提交+推送
• 我们将准备工作合并到staging
• 客户批准staging
上的工作
• 我们将工作合并到master，并将故障单部署在生产
上

问题：

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

问题是当客户批准这些特定的门票并且我们将工作合并到master时，我们必须再次修复冲突

重要提示：

• 我们无法将登台合并到主人 - 因为未经批准的门票
• 默认情况下，所有分支都是从最新的主分区
创建的
• 正在同时开发多张票，但在获得批准时会部署
如果工作已获批准+已部署，
• 从主服务器进行变基以避免冲突只是一种选择
• 从暂存中重新定位是而不是一个选项 - 因为未经批准的门票

有关如何解决此问题的任何想法？我们的工作流程有缺陷吗？我们错过了一些git hack吗？

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

谢谢

Answer 1

看看branch per feature。你应该得到关于这个主题的帖子。我在这里也回答了一个关于Sharing rerere cache

的问题

Answer 2

您需要让master和staging尽可能彼此靠近。您可以尝试以git本身pu分支的方式处理它。也就是说，当一个新任务完成时，分支被删除，从master重新创建并且所有待批准的功能都被合并。这样做的好处是分支不会分叉，取消合并被拒绝的功能没有问题。缺点是你不能以任何工作为基础，但你无论如何也不能。

当出现冲突时，你要么调整dev分支以便干净地合并并运行“章鱼”合并（与超过2个父项合并）再次创建staging，或者等待任何依赖或冲突的功能是在尝试上演受抚养人之前获得批准。

在任何情况下，功能分支应该在尝试暂存之前重新定位（或合并）最新master。它们是在创建时由master制作的，所以在后来的master上对它们进行重新定位就好像它们在以后启动并且发展得更快，这显然不会出错。