Merge or Rebase

Merge or Rebase？

    在 Git 合并分支的过程中，大多数人会产生这样的疑问，使用 Merge 还是 Rebase？今天我们就来聊一聊这个话题。首先，我们回顾一下 Merge 和 Rebase 操作

Merge

• git pull remote-name remote-branch
• 将远程代码的 master 分支同步到本地的 feature 分支，merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下，会提交合并中修改的内容
• merge 的提交历史，真实地记录了实际发生过什么，关注点在「真实的提交历史」上面

Rebase

• git pull remote-name remote-branch
• 将远程代码的 master 分支同步到本地的 feature 分支，rebase 提取了远程仓库 master 分支的修改，将其复制在了本地 feature 分支的最新提交的后面
• rebase 的提交历史反映了项目过程中发生了什么，关注点在「开发过程」上面

merge or rebase？

• 好了，大家对 merge 和 rebase 已经有了简单的回顾，接下来我们就聊一聊「merge or rebase」
• 在回答这个问题之前，我们不妨退后一步，想一下提交历史到底意味着什么？

  • 有一种观点认为，仓库的提交历史即记录实际发生过什么，它是针对历史的文档，本身就有价值，不能乱改。从这个角度来看，改变提交历史是一种适度，你使用谎言掩盖的实际发生过的事情，如果由合并产生的提交历史是一团糟怎么办？既然就是如此，那么这些痕迹就应该被保留下来，让后人查阅
  • 但是另一种观点正好相反，他们认为提交历史是项目过程中发生的故事，没有人会去出版一本书的第1批草稿，软件维护手册页是需要反复修订才能方便使用，持这一观点的人会使用 rebase，怎么方便后边的读者就怎么写
• 现在让我们回到之前问题上来，到底是 rebase 变基好还是直接的 merge 好，这并没有简单的答案，git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队每个项目对此的需求并不相同，既然我们已经学习了两者的用法和原理，相信我们以后在日后的开发中能做出明智的选择

❝

文章最后，给大家介绍一个 GitHub fork 的冷知识

• 在最早以前在 GitHub 上 fork 是一个贬义词，它指的是某个人使开源项目向不同的方向发展，或者说他创建了一个竞争项目，使得原项目的贡献者变得分裂
• 后来（也就是现在的意思） fork 的意思是指在远程服务器创建一个完全属于开发者自己的项目副本，并且对其有推送权限。如果我们想参与某个项目，但是并没有推送权限，这时我们可以对这个项目进行 fork

❞

---

关注「小小猿若尘」微信公众号，获取更多IT技术、干货知识、热点资讯