Azure DevOps合并release分支到master的合并类型选择及安全性疑问

提示含义说明 #

Squash 合并的逻辑是把源分支上的所有提交压缩成1个全新的提交，再合并到目标分支，这个全新的提交和源分支上的原有提交没有任何关联关系。
如果后续你还要继续使用该源分支（比如合并完release到master之后，还要基于这个release分支改bug、切新的开发分支），下次再往master合并的时候，Git 无法识别两边历史的关联，会出现大量重复的提交冲突，排查和解决成本极高。所以系统才会提示你如果要续用源分支，优先选 no-fast-forward 合并，后者会生成一个明确的合并节点，同时保留两边所有提交的关联关系，后续合并不会出现历史错位的问题。

Rebase and fast-forward 是否安全 #

这个合并方式本身不存在安全问题，核心要看你的使用场景是否匹配：
它的逻辑是先把源分支的所有提交变基到目标分支的最新提交后面，再执行快进合并，不会生成额外的合并提交，最终目标分支的历史是一条干净的线性提交链。
但是它有两个前提要注意：

• 你的源分支没有被多人同时协作修改，如果有其他人也在往这个源分支推送提交，你 rebase 之后强制推送会覆盖其他人的提交，其他人拉取你 rebase 后的分支也会出现历史冲突
• 你不需要在分支上保留合并节点的溯源信息，git-flow 流程里本来需要明确标记 release/hotfix 分支合并到 master 的节点，方便后续版本回溯，rebase 快进合并不会生成这个节点，对溯源会有影响。

适配 git-flow 流程的合并建议 #

你的需求是完整保留所有提交历史、降低后续 hotfix 和新版本迭代的问题，优先按以下规则选择合并类型：

• 把 release/hotfix 分支合并到 master、develop 分支时：选 Merge (no fast-forward)，会生成明确的合并节点，完整保留 release 分支上的所有提交历史，后续不管是切 hotfix 还是新的 release 分支，Git 都能正确识别分支分叉点，不会出现历史冲突
• 把功能分支合并到 develop 分支时：如果是单人开发的功能分支，要干净的历史可以选 Rebase and fast-forward；如果是多人协作的功能分支，选 Merge (no fast-forward) 即可
• 除非你确定合并后源分支就直接删除不再使用，否则不要选 Squash commit，完全不符合 git-flow 要长期维护多版本分支的需求
• Semi-linear merge 是介于 no-fast-forward 和 rebase 快进之间的选项，会先把源分支变基到目标分支最新节点，再生成一个合并提交，既保证目标分支历史干净，又有合并节点溯源，也可以作为 release 合并到 master 的备选方案。

内容的提问来源于stack exchange，提问作者ab_732