（不是那样）假设案例

情况是最常见的情况：有master分支从不接收直接提交。如果我需要做一些事情，我会创建一个feature/personal分支（通常使用长寿的个人分支比脂肪特征分支更频繁）。一旦我对我创建的代码感到满意，我想把它带回master（同时，它已收到另一个提交）。

重要的是要指出master和branchX始终被推送到远程。

因此，以图形方式澄清它，我们处于这种情况（我将使用 C 进行提交， M 进行合并）：

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

当前工作流程

当前使用的工作流程可以定义为合并/合并：因为我不想修复master中的合并冲突，首先我合并 master内的branch1，然后branch1中的合并 master。

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

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

我个人认为这个解决方案有两个主要原因：

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

我建议的是常见且更直接的 rebase-before-merge-down 工作流程。

一旦我想在branch1中合并master，首先我 rebase 后者的前者，所以我处理我的分支中的所有冲突;比我合并 branch1到master（如果功能分支有意义，则使用NO-FF，否则使用FF）

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

然而，这个解决方案有一个主要缺点：

由于两者都与遥控器同步，因此需要git push --force。所以，如果有人做错了事（因为他匆忙，分心或愚蠢），可能会在一秒钟内失去数周的工作。

另一方面，优点应该是：

您在大型团队中采用哪种可扩展的工作流来保持git历史记录的清晰和有意义，另一方面，防止像git push --force这样的潜在灾难可以做到？

Answer 1

根据我的经验，一个常见的模型是：

有权威的主存储库。
- 此处的master分支只能通过拉取请求进行更新（按照您的说法，向下合并）。
- 是否可以强制推送到其他分支机构是在特定的基础上确定的（往往取决于实际需要多少人同时在分支机构上工作）。
每个人都维护自己的主存储库分支。
- 他们可以随时强行推进自己的分支机构。
- 要将更改合并到主存储库的master分支，请将您的分支重新绑定到master并提取请求。

发布更难处理。

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

Answer 2

如果branchX（例如branch1）适合您自己，您可以按照自己的方式使用：合并前的rebase。

如果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结帐功能分支。

BTW：我需要更正您当前工作流程中使用的图表。将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