半线性合并

Question

我刚刚注意到在 Azure DevOps 中有一个名为semi-linear merge. 我想知道它有什么作用？它是否介于合并策略和变基策略之间（名称为半线性）？如果是这样，有什么优点/缺点？

编辑：从Microsoft Devblog我相信这个选项包括 2 点：

1. 从 master/dev 分支重新设置功能分支
2. 然后在 master/dev 分支中合并 feature 分支

但这不是合并策略吗？

Answer 1

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

有些人认为这是两全其美的：保留个人提交，以便您可以看到工作是如何演变的，但不仅仅是重新定位，而是显示“合并气泡”，以便您可以立即看到工作每个单独的拉取请求。

取自带有 Rebase 的拉取请求

Answer 2

半线性合并只是添加了一个 rebase，以便在完成合并之前让您的分支保持最新状态。如果您正在 PR'ing my-branchinto 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 之前测试合并提交并运行测试，只是为了确保常规合并仍然按预期工作。）
2. 合并（使用 --no-ff）强制合并提交，这很有用，因为每个 PR 包含与该 PR 关联的提交列表，使您能够查看显示所有合并到分支的第一父历史记录，并轻松比较它们。强制合并提交的另一个好处是，只需还原合并提交即可轻松还原整个 PR，而不是单独还原原始 PR 中的每个提交。

缺点：

• 在某些情况下，您只是不想使用半线性合并。一个很好的例子是，如果您的源分支中有您想要保留的新合并提交。在 Git Flow 中，当您将release合并到master，或将master合并回develop 时，您需要保留来自这些分支上的 PR 的任何合并提交。半线性合并的 rebase 部分将重写那些合并提交，不仅会弹出“气泡”，更糟糕的是，提交 ID 将被重写。这意味着您无法确定master 中的所有内容当前是否正在开发中. 尽管代码相同，但可能缺少 ID。根据经验，如果源分支包含新的合并提交，就不要进行半线性合并。
• 半线性合并后，删除本地分支时，您可能必须使用git branch -D my-branch（而不是小写 -d），因为提交 ID 可能已更改。除非您通常不立即删除本地分支，否则这几乎不会带来不便；如果你等待，你需要确认你真的可以删除它。
• 如果您的工作流程是让开发人员在创建他们的 PR 之前 rebase 到目标分支，那么提供这个选项可能会让他们变得懒惰，因为他们知道这会为他们做。大多数时候这不是问题，但每隔一段时间自动合并或变基都会破坏某些东西，并且最好让他们习惯于在 PR 完成之前先变基以检测它。否则，在这种（公认的罕见）场景中，冲突会自动解决，并且您的集成分支会出现问题。
• 如果您使用签名提交，如果在半线性合并期间需要变基，则不会保留签名（因为提交被重写）。根据为什么你要签名你的提交，这可能不是一个可以接受的选择。

旁注：其他工具也提供此功能：

• Bitbucket 提供了相同的合并策略，并适当地将其称为“Rebase、merge”。
• GitLab 有一个强制“使用半线性历史合并提交”的设置，但是，在撰写本文时，AFAIK 只是 MR 上的一个门。（注意 GitLab 将 Pull Requests 称为“Merge Requests”。它们是相同的东西。）启用此设置后，您必须首先自己重新设置它的基础（您可以在 UI 中执行此操作），然后您完成 MR。基本上它是 2 次按钮点击而不是 1 次。
• 尽管人们自 2017 年以来一直在请求它，但 GitHub 尚不支持此功能。

附加说明：我无法在任何地方找到此文档，但我已经测试并确认，在 Azure DevOps 中完成 PR 时，如果您选择“Rebase and fast-forward”或“Semi-linear merge”，您的 PR 来源在 PR 完成之前重写分支。通常，您会在合并后勾选删除源分支的框，并且不会关心这一点，但是如果您选择不选中该设置，那么重要的是要意识到您的远程分支将显示为“（强制更新）”在如果需要变基，则您的下一个本地获取。根据您的用例，这可能是 Pro 或 Con；大多数情况下，我倾向于更喜欢这个。

至于其他工具，这一战略GitLab力量你更新一个按钮点击您的分支，专门到位桶也没有修改PR分支在其相当于“再次基于，合并”的策略。