使用git rebase和git merge建立良好的团队工作流

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

（并非如此）假设情况 这种情况最常见：有一个

master

分支从未收到直接提交。如果我需要做一些事情，我会创建一个

feature/personal

分支（通常使用长寿命的个人分支比feature分支更频繁）。 一旦我对自己创建的代码感到满意，我想把它带回

主控

（同时，它又收到了另一个提交）

需要指出的是，

master

和

branchX

总是被推到远程

因此，为了从图形上阐明这一点，我们处于这种情况（我将使用C进行提交，M进行合并）：

branch1c2--C3--C6--C9---
/
主机C0---C1---C4---C5---C7---C8

当前工作流 当前使用的工作流可以定义为向上合并/向下合并：因为我不想修复master中的合并冲突，首先我在

branch1

中向上合并

master

，然后在

master

中向下合并

branch1

branch1c2--C3--C6--C9--M1
/                    /\
主机C0---C1---C4---C5---C7---C8 M2

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

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

• 这导致了一个非常混乱的历史树
• 将父分支合并为子分支对我来说毫无意义

另一方面，我的同事认为：

• 这很容易理解，即使不是专业的实习同事
• 它会导致更少的错误，因为您未触及历史记录（与rebase不同）

提议的解决办法 我提出的是一种常见且更直接的在合并之前重新设置基础的工作流

一旦我想在

master

中合并

branch1

，首先我会在后者的基础上重新设置前者，以便处理分支中的所有冲突；然后我将

branch1

合并到

master

（如果特征分支有意义，则不使用FF，否则使用FF）

branch1c2--C3--C6
再基/\
主机C5---C7---C8 M1

但是，此解决方案有一个主要缺点：

由于两者都与遥控器同步，因此需要一个git push--force。因此，如果有人做错了什么事（因为他很匆忙、心烦意乱或愚蠢），几周的工作可能会在一秒钟内损失

另一方面，优势应该是：

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

那么，问题是什么？

---

在您的大型团队中，您采用了哪种可扩展的工作流来保持git历史记录的干净和有意义，并在另一方面防止潜在的灾难，如错误的git push--force可以做到？

在我的经验中，一个常见的模型是：

• 有一个权威的主存储库。
  • 这里的

    master

    分支只能通过pull请求更新（用你的说法，是向下合并）
  • 您是否可以强制推送到其他分支取决于临时基础（往往取决于实际需要在一个分支上同时工作的人数）
• 每个人都维护自己的主存储库分支。
  • 他们可以在任何时候强迫自己的分支
  • 要将更改合并到master存储库的

    master

    分支中，您需要将分支重新设置到

    master

    上，并将请求拉入

释放要复杂得多

我建议看看Linux、Git、Node等开源项目是如何维护它们的存储库的，并考虑到这一点。

如果

branchX

（例如

branch1

）是为您自己工作的，您可以使用您想要的方式：在合并之前重新设置基础

如果

branchX

（例如

branch1

）适用于所有开发人员，则最好不要使用您预先提出的解决方案，这是您所说的主要缺点，其他开发人员会感到困惑，并且他们可能再也找不到自己的更改

有一种方法可以使用：

git merge branch1--squash

。 假设您的git日志是：

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

，它只是一个快进合并。

branch1

和

master

都指向

M1

立即提交

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

---

你得到帮助你解决问题的答案了吗？如果是，请标记它。你是对的，我上周真的很忙，我没有找到合适的时间来回答和标记解决方案：）谢谢：）从未使用挤压合并，真的很有趣！但是，这对我的情况没有帮助，因为我的同事希望避免在主分支上解决合并冲突（这就是为什么他们通常在主分支中合并分支之前在分支中合并主分支）。及