了解 git rebase
大多数人习惯使用 git merge 将更改从功能分支合并到主分支，但还有其他方法。我们是否曾经遇到过 git rebase 这个术语并想知道它是什么？或者我们可能听说过 rebase 和 merge ，但不确定何时使用哪个？不用担心，因为本文就是关于 git rebase 的介绍及使用。
什么是 git rebase？
为了理解 git rebase，我们首先需要掌握 Git 本身。Git 是一个分布式版本控制系统，这意味着它有助于管理项目随时间的变化。将其视为代码的神奇时间机器；它允许我们在不同版本之间来回切换。
git rebase 是一个命令，可以帮助我们将更改的代码从一个分支集成到另一个分支。想象一下我们正在建造一座塔，我们已经建立了一个坚固的基础，但在中途，我们决定在不影响上面的结构的情况下改 rebase 础。这就是 rebase 的作用 —— 它改变了分支的基础。
用技术术语来说，rebase 是将一系列提交移动或组合到新的基础提交的过程。
rebase 和 merge
为了更深入地探讨，让我们把 rebase 与 merge 进行比较。假设我们有一个包含主分支和功能分支的 git 存储库，并且我们希望将功能分支更改合并到主分支。我们的存储库可能如下所示：
标准方法是将功能分支使用 merge 合并到主分支。这会在主分支上创建一个新的提交，添加累积更改并将其作为合并提交添加到主分支上。这会保留其他功能分支的历史记录，以备我们需要时再次使用。
或者，我们可以使用 rebase 我们的代码。这将获取功能分支的更改并将它们附加到主分支，这有效地删除了作为单独工作分支的历史记录。
功能：
- merge ：从一个分支获取所有更改并将它们合并到另一个分支中，创建一个新的合并提交。
- rebase：从一个分支获取更改并在另一分支之上“重播”它们。
提交记录：
- merge：维护原始分支历史记录并添加一个新的提交，显示两个分支的合并位置。
- rebase：通过 rebase 将分支的整个历史记录放在其移动到的分支顶部来提供线性历史记录。
还有另一种理解它的方式：假设我们正在写一个故事。merge 就像在中间添加一章来解释前面章节中发生的事情。另一方面，rebase 就像重新安排章节以使故事更加流畅。
git rebase 的优点和缺点
优点：
- 更清晰的项目历史记录：rebase 提供了更精简、线性的项目历史记录。
- 消除不必要的提交：通过重放提交，可以使提交历史记录更清晰、更容易理解。
- 灵活的工作流程：有经验的开发者可以在 rebase 过程中修改提交、更改提交消息或将多个提交压缩为一个。
缺点：
- 复杂性：对于初学者来说，rebase 可能更加复杂且难以理解。
- 潜在的冲突：如果操作不当，rebase 可能会引入冲突，而解决起来可能很棘手。
- 更改提交历史记录： rebase 会重写项目历史记录，这可能不是所有项目都需要的。
何时使用rebase
考虑到它的优点和缺点，我们可能会考虑在以下情况下使用 git rebase 方法：
- 清理本地提交：在将提交推送到公共分支之前，我们可以使用 rebase 来清理提交历史记录。
- 避免合并提交：如果我们想要线性提交历史记录而不需要合并提交。
- 集成上游更改：如果我们正在处理功能分支并且主分支已更新，我们可以 rebase 以将这些更改集成到我们的功能分支中。
- 协作项目：与团队合作时，确保我们的分支与主分支保持同步。
但是，请记住不要对公共分支或与其他开发人员共享的分支进行 rebase ，因为这可能会导致混乱和冲突。
不要对与其他开发人员共享的分支进行 rebase 。 rebase 非常适合使我们的本地提交更加清晰，但它是一个更改重写命令。一旦提交公开，我们应该认为它们是不可变的。
技巧和窍门
- 保持安全：在 rebase 之前始终创建一个备份分支，这样如果出现问题，我们就有办法恢复。
- 增量 rebase ：如果我们要对一长串提交进行 rebase ，请考虑增量 rebase 以一次解决一个冲突。
- 使用 -i 表示：交互模式 ( git rebase -i) 允许我们根据需要压缩、编辑或重新排序提交。
- 不确定时使用 abort：如果我们觉得自己搞砸了或处于冲突状态，请使用git rebase --abort 取消 rebase 并恢复到原始状态。
- 经常练习：在将其应用于实际项目之前，使用本地 git 存储库来练习 rebase。
