来看两种场景中merge的不同方式。场景一：切出特性分支后，develop分支上没有新的提交。
fast-forward，若无分歧，会直接移动文件指针。看不出特性分支的起始点。no-fast-forward（--no-ff），保留提交链的完整性。squash，压缩不必要的commit；无法看出feature分支合到develop；feature，develop保持相对独立。场景二：切出特性分支后，develop分支上提交了C6，C7。develop分支上提交了C6，C7，无法fastforward。threewaymerge，找到d
Git是世界上最流行的分布式版本控制系统，它的两大合并策略——`git merge` 和 `git rebase` 是开发者日常工作中不可或缺的部分。这两个命令在不同场景下有着不同的应用，理解和掌握它们的使用方式对于保持代码仓库的整洁和协作效率至关重要。
我们来看`git merge`。`git merge` 的主要目的是合并两个分支的差异，它会在你的当前分支中加入指定分支的所有变更。当合并一个特性分支（feature）到主分支（如develop）时，有两种常见场景：
1. **Fast-forward Merge**: 如果你在创建特性分支后，主分支没有新的提交，`git merge` 将执行快速向前合并（fast-forward）。这种情况下，特性分支的提交历史会被直接插入到主分支的历史中，看上去就像主分支直接向前推进，无法看出特性分支的起点。
2. **No-Fast-Forward Merge**: 当主分支有新的提交时，`git merge` 会执行非快速向前合并（--no-ff）。这种合并保留了提交链的完整性，即在主分支上创建一个新的合并提交，同时包含两个分支的最新状态。这样可以清楚地看到哪个提交是合并的结果。
3. **Squash Merge**: 另一种特殊形式的合并是`git merge --squash`，它会将特性分支的所有提交压缩为一个提交，然后合并到主分支。这样特性分支的修改看似一次性完成，无法看出每个单独的特性分支提交。
接下来是`git rebase`。`git rebase` 的核心思想是将一个分支的修改应用于另一个分支的基线上，创建一个线性的提交历史。它将从旧基线（old base）到新基线（new base）之间的一系列提交在新基线上重新应用。这使得版本树看起来更加整洁，因为所有的提交都沿着一条直线发展。
1. **与主分支同步**: 当你在一个分支上开发时，如果主分支有新的变更，使用`git rebase` 而不是`git merge` 可以保持一个干净的提交历史。这尤其适用于你想要将本地的开发工作基于主分支的最新状态。
2. **恢复搁置的开发**: 如果你很久没处理某个分支，现在想重新开始，`git rebase` 可以帮助你将工作基于最新的主分支，避免了大量的合并冲突。
3. **整理本地历史**: 在提交到公共仓库之前，`git rebase -i` 允许你交互式地整理提交历史，例如合并连续的提交，修正消息，或者删除不必要的提交。这确保公共仓库中的提交历史清晰且有意义。
虽然`git rebase` 很强大，但有一些注意事项。一旦一个分支被推送到公共仓库，就不应该再对其执行`git rebase`，因为这会改变公共历史，可能会导致他人同步时的混乱。因此，`git rebase` 主要用于个人的、未公开的分支，而`git merge` 通常用于合并那些需要保留完整历史的分支，如bug修复分支或特性分支。
选择`git merge` 还是`git rebase`，取决于你希望如何展示分支历史以及分支的重要性。对于短期的、本地的、临时的分支，`git rebase` 可以提供一个更简洁的提交历史。而对于长期维护或重要的分支，`git merge` 保留了完整的历史信息，便于跟踪和理解项目的演变。
