【问题标题】:Using git rebase and git merge to set up a good team workflow使用 git rebase 和 git merge 建立良好的团队工作流程
【发布时间】:2017-03-14 20:39:23
【问题描述】:

我知道有很多类似的问题,但我找不到一个好的答案来帮助我在我工作的公司提出一个好的解决方案。我们的开发人员不多,但我想提出一个可扩展的工作流程。

(并非如此)假设情况

这种情况是最常见的:有一个master 分支从不接收直接提交。如果我需要做某事,我会创建一个feature/personal 分支(通常使用长寿命的个人分支比使用胖特性分支更频繁)。 一旦我对我创建的代码感到满意,我想把它带回master(与此同时,它已经收到了另一个提交)。

重要的是要指出masterbranchX 总是被推送到远程。

所以,为了以图形方式澄清它,我们处于这种情况(我将使用 C 进行提交,M 用于合并):

branch1 C2---C3---C6---C9--- / master C0---C1---C4---C5---C7---C8

当前工作流程

可以定义当前使用的工作流程merge-up/merge-down:由于我不想修复master中的合并冲突,首先我merge-up masterbranch1 中,然后我 合并 branch1master 中。

branch1 C2---C3---C6---C9---M1 / /\ master C0---C1---C4---C5---C7---C8 M2

这样做,我解决了分支内部的冲突,然后我可以将我的分支合并到 master。

我个人不喜欢这个解决方案,主要原因有两个:

  • 它会导致一棵非常混乱的历史树
  • 将父分支合并到子分支听起来对我来说毫无意义

另一方面,我的同事认为:

  • 这很容易理解,即使对于非专业实习同事也是如此
  • 由于您未触及历史记录,因此导致错误更少(与变基不同)

建议的解决方案

我提出的是通用且更直接的 rebase-before-merge-down 工作流程。

一旦我想将branch1 合并到master 中,首先我rebase 前者基于后者,所以我处理了我分支中的所有冲突;比我 合并 branch1master (如果功能分支有意义则使用 NO-FF,否则使用 FF)

branch1 C2---C3---C6 rebase / \ master C5---C7---C8 M1

然而,这个解决方案有一个主要缺点:

由于两者都与遥控器同步,因此需要git push --force。因此,如果某人做错了事(因为他匆忙、分心或愚蠢),数周的工作可能会在一秒钟内浪费掉。

另一方面,优点应该是:

  • 保持历史树非常干净和有意义
  • 展平并移除无用的分支,只保留相关的分支

那么,这个问题?

在您的大型团队中,您采用哪种可扩展的工作流程来保持 git 历史记录的整洁和有意义,另一方面,防止像错误的 git push --force 那样的潜在灾难?

【问题讨论】:

  • 你得到了帮助你解决问题的答案吗?如果是,请标记它。它将帮助其他有类似问题的人。
  • 你说得对,我上周真的很忙,没有找到合适的时间来回答和标记解决方案:)

标签: git version-control merge workflow rebase


【解决方案1】:

根据我的经验,一个常见的模型是这样的:

  • 有一个权威的 ma​​ster 存储库。
    • 此处的master 分支只能通过拉取请求(用您的话说,向下合并)进行更新。
    • 您是否可以强制推送到其他分支取决于临时确定(往往取决于实际需要同时在一个分支上工作的人数)。
  • 每个人都维护自己的主存储库分支。
    • 他们可以随时强制推送到自己的分支。
    • 要将更改合并到 ma​​ster 存储库的 master 分支中,请将分支变基到 master 并拉入请求。

发行版更难处理。

我建议查看 Linux、Git、Node 等开源项目如何维护其存储库并将其考虑在内。

【讨论】:

  • 谢谢,拉取请求可能是一个可行且直接的解决方案,也在同一个存储库中:)
【解决方案2】:

如果branchX(如branch1)适合你自己,你可以使用你想要的方式:rebase before merge。

如果branchX(如branch1)适用于所有开发者,你最好不要使用你的前置解决方案,主要缺点正如你所说的其他开发者会感到困惑,他们可能找不到自己的变化没有了。

您可以使用一种方法:git merge branch1 --squash。 假设你的 git log 是:

branch1         C2---C3---C6---C9---
               /
master   C0---C1---C4---C5---C7---C8

在你执行git merge branch1 --squash之后,git日志会是这样的:

branch1         C2---C3---C6---C9
               /
master   C0---C1---C4---C5---C7---C8---M1

这使您的master 分支看起来更清晰。如果您想开发新功能,可以直接从master 签出功能分支。

顺便说一句:我需要更正您在当前工作流程中使用的图表。 将master 合并到branch1 后,图形看起来像

       C2---C3---C6---C9---M1  branch1
      /                   /
C0---C1---C4---C5---C7---C8  master

branch1 合并到master 后,默认没有提交M2 来创建,它只是一个快进合并。 branch1master 都指向 M1 现在提交。

       C2---C3---C6---C9---M1  branch1, master
      /                    /
C0---C1---C4---C5---C7---C8 

【讨论】:

  • 谢谢 :) 从来没有使用过压缩合并,真的很有趣!但是,这对我的情况没有帮助,因为我的同事希望避免解决 master 分支上的合并冲突(这就是为什么他们通常在合并 master 分支之前将 master 合并到分支中的原因)。感谢您的纠正,您完全正确;)
猜你喜欢
  • 2019-06-08
  • 2013-12-23
  • 1970-01-01
  • 2018-03-05
  • 2018-04-28
  • 1970-01-01
  • 2013-05-15
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多