半线性合并

这种策略是最奇特的--它混合了变基和合并。首先，pull请求中的提交在master分支的顶部重新定基。然后，这些重基拉请求被合并到主分支。它模拟在pull request分支上运行git rebase master，然后在master分支上运行git merge pr --no-ff。

有些人认为这是两全其美：单个的提交被保留，这样你就可以看到工作是如何发展的，但不是仅仅被重新定基，而是显示一个“合并气泡”，这样你就可以立即看到每个单独的拉取请求中的工作。
来源：Pull Requests with Rebase

半线性合并只是在完成合并之前添加一个变基以使分支保持最新。如果要将my-branch PR到target-branch，则与以下命令相同：

git fetch
git checkout my-branch
git rebase origin/target-branch
git branch -D target-branch # just in case you have an old version of it locally
git checkout target-branch
git merge --no-ff my-branch

一些优点和缺点如下：

优点：

1.变基首先使每个合并更清晰，更容易在视觉上跟踪。它还将所有更改放入提交本身，而不必在合并提交中跟踪不希望的副作用，这通常很困难。注意，仍然建议开发人员在创建PR之前进行一次rebase，这样他们就可以见证当时发生的任何更改，并针对最新版本运行单元测试，以确保没有任何异常发生。（这类似于在创建PR之前测试合并提交并运行测试，只是为了确保常规合并仍然按预期工作。）

1. merge（使用--no-ff）强制合并提交，这很有帮助，因为每个PR都包含与该PR关联的提交列表，使您能够查看第一父代历史，其中显示了分支中的所有合并，并轻松比较它们。强制合并提交的另一个好处是，通过简单地恢复合并提交，而不是单独地恢复原始PR中的每个提交，可以很容易地恢复整个PR。

缺点：

• 在某些情况下，您不想使用半线性合并。一个很好的例子是，如果你的源分支中有你想要保留的新合并提交。在Git Flow中，当你将 release 合并到 master，或者将 master 合并回 develop 时，你需要保留这些分支上PR的任何合并提交。半线性合并的rebase部分将重写那些合并提交，并且不仅将弹出“气泡”，而且更糟的是，提交ID将被重写。这意味着你不能确定 master 中的所有内容是否都在 develop 中。尽管代码相同，但可能缺少ID。根据经验，如果源分支包含新的合并提交，就不要做半线性合并。
• 在半线性合并之后，当删除本地分支时，您可能必须使用git branch -D my-branch（而不是小写的-d），因为提交ID可能已经更改。这几乎不是一个不便，除非你一般不删除您的本地分支机构的权利;如果您等待，您将需要确认您确实可以删除它。
• 如果你的工作流程是让开发人员在创建PR之前重新定位到目标分支上，那么这个选项可能会让他们变得懒惰，因为他们知道它会为他们做这件事。大多数情况下这不是问题，但偶尔自动合并或变基都会破坏一些东西，最好是他们习惯于在PR完成之前首先进行变基以检测它。否则，在这种情况下（诚然很少见），冲突会自动解决，集成分支中会出现一些中断。
• 如果使用签名提交，如果在半线性合并期间需要重基，签名将不会被保留（因为提交被重写）。根据你为什么要签署你的提交，这可能不是一个可以接受的选择。
  **旁注：**其他工具也提供此功能：
• Bitbucket offers the identical merge strategy，并适当地称之为“Rebase，merge”。
• GitLab曾经有一个强制“半线性历史合并提交”的设置，然而，在写这篇文章的时候，AFAIK只是MR上的一个门。（注意GitLab将Pull Requests称为“Merge Requests”。它们是一回事。）使用此设置，您必须首先自己重定它的基（您可以在UI中执行此操作），然后完成MR。基本上它是2个按钮点击而不是1。更新：这可能不再可能。现在GitLab有一个fast-forward only的选项，但我不知道你是否可以要求检查分支是否是最新的，并仍然执行--no-ff合并。
• GitHub目前还不支持这一功能，尽管自2017年以来人们一直在请求它。
  **附加说明：**我在任何地方都找不到此文档，但我已经测试并确认，在Azure DevOps中完成PR时，如果您选择“Rebase and fast-forward”或“Semi-linear merge”，则PR源分支将在PR完成之前重写。通常情况下，你会在合并后勾选框来删除你的源分支，并且不会关心这个，但是如果你选择不选中该设置，那么重要的是要意识到你的远程分支将在你的下一次本地提取时显示为“（强制更新）”，如果需要变基的话。这可能是一个优点或缺点，具体取决于您的用例;大多数时候我倾向于更喜欢这样。

关于其他工具，GitLab使用此策略强制 * 您 * 通过单击按钮更新分支，而Bitbucket特别不 * 修改PR分支，其等效的“Rebase，合并”策略。