0

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

staging即测试环境

master即生产环境

dev/XXX其中 XXX 是票号

  • 客户登录票据
  • 我们创建一个分支，例如dev/2332
  • 我们工作+提交+推送
  • 我们将准备好的工作合并到staging
  • 客户批准工作staging
  • 我们将工作合并到master生产中并部署票证

问题：

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

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

重要的：

  • 我们无法将 staging 合并到 master 中——因为票证未经批准
  • 默认情况下，所有分支都是从最新的 master 创建的
  • 多个工单正在同时开发，但在批准后部署
  • 仅当工作已获得批准+已部署时，才可以从 master 重新定位以避免冲突
  • 从暂存中重新定位不是一种选择 - 因为未经批准的票证

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

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

谢谢

4

2 回答 2

2

查看每个功能的分支。你应该得到我关于这个主题的帖子。我还在这里回答了一个关于共享 rerere 缓存的问题

于 2012-10-03T23:54:28.067 回答
0

您需要保持master并staging尽可能靠近彼此。您可以尝试以 git 本身pu分支的方式处理它。也就是说，当一项新任务完成时，将删除、重新创建分支，master并将所有待批准的功能合并到其中。这样做的好处是分支不会分歧，并且不存在取消合并被拒绝功能的问题。缺点是您无法在此基础上进行任何工作，但无论如何您都不会。

当发生冲突时，您可以调整开发分支以干净地合并并运行“章鱼”合并（与超过 2 个父级合并）staging再次创建，或者在尝试暂存依赖项之前等待任何依赖项或冲突功能得到批准.

在任何情况下，特性分支都应该在尝试暂存它们之前重新基于（或合并）最新master的。它们在创建时是由 master 制作的，因此将它们重新定位在后来的 master 上就像它们是后来开始的并且开发得更快，这显然不会错。

于 2012-10-03T17:57:51.080 回答