11. 什么时候使用 rebase 代替 merge ？

这两个命令都是把修改从一个分支集成到另一个分支上，它们只是以非常不同的方式进行。

  • 考虑一下场景，在合并和变基前：

    A <- B <- C [master] ^ D <- E [branch]

  • 在 git merge master 之后：

    A <- B <- C ^ ^ D <- E <- F

  • 在 git rebase master 之后：

    A <- B <- C <- D <- E

使用变基时，意味着使用另一个分支作为集成修改的新基础。

  • 何时使用：
    • 如果你对修改不够果断，请使用合并操作。
    • 根据你希望的历史记录的样子，而选择使用变基或合并操作。
  • 更多需要考虑的因素：
    • 分支是否与团队外部的开发人员共享修改（如开源、公开项目）？如果是这样，请不要使用变基操作。变基会破坏分支，除非他们使用 git pull --rebase ，否则这些开发人员将会得到损坏的或不一致的仓库。
    • 你的开发团队技术是否足够娴熟？变基是一种破坏性操作。这意味着，如果你没有正确使用它，你可能会丢失提交，并且/或者会破坏其他开发者仓库的一致性。
    • 分支本身是否代表有用的信息？一些团队使用功能分支（branch-per-feature）模式，每个分支代表一个功能（或错误修复，或子功能等）。在此模式中，分支有助于识别相关提交的集合。在每个开发人员分支（branch-per-developer）模式中，分支本身不会传达任何其他信息（提交信息已有作者）。则在这种模式下，变基不会有任何破坏。
    • 是否无论如何都要还原合并？恢复（如在撤销中）变基，是相当困难的，并且/或者在变基中存在冲突时，是不可能完成的。如果你考虑到日后可能需要恢复，请使用合并操作。