【Git】Merge的不同方式（Fast-forward Merge、Squash Merge、No Fast-forward Merge、Don’t Commit Merge）

记录一下不同的merge方式，这些命令的核心区别其实就在于如何将源分支的提交历史记录到目标分支上。这里举例原分支dev，目标分支test。

下面是每个选项的详细解释和区别：

1. Merge (默认的 Fast-forward Merge)

• 命令：git merge dev

• 含义：这是标准的合并。如果目标分支（test）的尖端是源分支（dev）的直接祖先（即目标分支没有新的提交，指针可以直接前移），Git 会执行“快进”操作。

• 结果：

  • 如果可快进：目标分支的指针直接移动到源分支的最新提交，历史记录是一条直线。不会产生额外的合并提交。

  • 如果不可快进：Git 会自动创建一个新的“合并提交”来将两个分支的历史联系在一起。

• 适用场景：希望保持历史简洁，并且不介意丢失分支信息（在可快进的情况下）。

2. Fast-forward Merge --ff-only

• 命令：git merge --ff-only dev

• 含义：只允许快进合并。如果由于目标分支有新的提交而导致无法快进，则合并操作会直接失败（而不是自动创建合并提交）。

• 结果：

  • 可快进：与上述 Merge 行为一致，快进成功。

  • 不可快进：合并中止，并提示错误。你的分支状态保持不变。

• 适用场景：你只想更新分支到最新状态，并且明确拒绝创建合并提交。如果失败，提醒你需要先处理目标分支上的变更（例如先 rebase）。

3. Squash Merge --squash

• 命令：git merge --squash dev

• 含义：将源分支（dev）上的 所有新提交的所有更改压缩成一个单一的变更集，并暂存（stage）到目标分支（test）的工作区中。它不会保留源分支的提交历史，也不会创建合并提交（需要你手动执行一次提交）。

• 结果：目标分支的历史记录中只会增加一个全新的提交，这个提交的内容是源分支所有更改的总和。这个新提交与原来的源分支没有直接的父级关系。

• 适用场景：功能分支开发完毕，希望将整个功能的所有更改作为一个简洁、完整的单元合并到主分支，避免带入大量琐碎的中间提交历史。

4. No Fast-forward Merge --no-ff

• 命令：git merge --no-ff dev

• 含义：禁止快进合并，即使条件允许。Git 一定会创建一个新的合并提交。

• 结果：目标分支的历史记录中会明确保留一次合并操作的证据，清晰地显示出这是一个分支被合并了进来。

• 适用场景：希望在任何情况下都在版本历史中明确保留分支的存在和合并行为，便于后续追踪。这是很多团队的推荐工作流。

5. Don‘t Commit Merge --no-commit --no-ff

• 命令：git merge --no-commit --no-ff dev

• 含义：执行合并操作（禁止快进），但在最终提交前暂停。它会准备好合并提交的所有内容（包括自动解决冲突后的结果），并将其放入暂存区，但不会真正完成提交。

• 结果：你可以检查暂存区的内容，在最终创建提交之前进行最后的修改、测试或添加遗漏的文件。

• 适用场景：你想对自动合并的结果进行最终审查或微调，然后再完成提交。这给了你一个在提交前修改合并结果的机会。