变基的风险
呃，奇妙的变基也并非完美无缺，要用它得遵守一条准则：
如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。
如果你遵循这条金科玉律，就不会出差错。 否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。 如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。
git stashgit stash 时，你的修改会被保存在一个未完成改动的栈中，可以在之后任何时候重新应用。
Fast-forward merge 和 Squash merge 都是Git中合并分支的方法，但它们在处理分支历史方面有显著的不同。
Fast-forward Merge
- 当你的当前分支完全落后于要合并的分支时，Git可以执行快进合并（fast-forward merge）。这意味着没有在当前分支上而在其他分支上进行的提交，所以Git仅仅是将HEAD指针移到最新提交上，实际上就是“追上”了变更历史。
- 快进合并不会创建一个新的合并提交，这使得历史记录看起来非常线性。
- 这种类型的合并保留了项目历史的实际发展路径，但如果你想保留特定分支的历史记录，这可能不是最佳选择。
Squash Merge
- 在执行Squash合并时，Git会将所有从分支开始以来的提交压缩成一个新的提交到目标分支上。这意味着不管有多少个提交，最终只会在目标分支上创建一个新的提交。
- Squash合并使得历史记录更加整洁，因为它将所有的变更压缩到一个提交中，这对于保持一个干净的主分支（如master或main）历史记录非常有用。
- 使用squash合并，原始分支的详细提交信息可能会丢失，因为所有的变更都被压缩到一个提交中。
- Squash合并不会自动删除源分支，因此在合并后需要手动删除分支来保持分支清晰。
使用场景
- Fast-forward Merge 更适合小规模的、频繁的更新，尤其是当你希望保留详细的分支合并历史时。
- Squash Merge 适合在将特性分支合并回长期分支（如main或master）之前，保持历史记录的简洁。它特别适用于大型特性开发，其中包含了许多中间提交，这些提交的历史记录对于最终的代码库可能不是很重要。
选择哪种合并策略取决于你的项目需求以及你想如何管理你的Git历史记录。