git merge和git rebase的区别, 切记：永远用r

git merge和git rebase的区别, 切记：永远用rebase

​

这一期来谈一下git merge和git rebase的区别。

Git无疑现在已经成为最流行的代码管理工具之一。其中有两个命令，对很多程序员造成了很多的困惑，一个是merge，一个是rebase。

这些困惑主要纠结于到底应该用merge还是用rebase。

在继续深入探讨之前，我先抛出我的观点。如果你想拥有一套稳定的，健壮的代码, 永远要使用rebase。

不为别的，就为了rebase可以给你提供一套清晰的代码历史。

相反的, merge会给你一套乱七八糟的代码历史。当你看到这样的代码历史的时候，我相信你绝对没有心情去研究每一个历史对应的代码。

好，接下来我们就详细分析一下这两个命令的作用。假设我们的repo有这么个主branch: master。

每个程序员在创建自己的代码之前，要首先创建自己的个人分支，然后代码修改开始。

假如你有6个程序员一起工作， 你就会有6个程序员的分支， 如果你使用merge, 你的代码历史树就会有六个branch跟这个主的branch交织在一起。

那个画风我相信对你一定很熟悉。想着那个画风感觉到一切都好无助， 有个词儿比较合适，叫做欲仙欲死。

这就是merge命令下生成的代码分支历史。

那么rebase又能做到什么程度呢？Rebase永远不会导致多个历史分支进行交织。它永远都是一条线。纯洁而又干脆。轻轻爽爽的， 从不拖泥带水。

那为什么会这样呢？

先说一下merge。Merge命令会保留所有commit的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是merge的命令初衷就是为了保留这些时间不被修改。这样也就形成了以merge时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录, 主分支上只保留merge的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge某branch到某branch上了。这个历史记录描述基本上是没有意义的。

还有一个比较有意思的是你不能，也不应该去修改这个历史记录描述。那是因为这个merge记录里面，不仅仅包含你自己的代码，也包含别人的代码。到这里你能想象有多乱吧？

再来说一下rebase, 这个命令会始终把你最新的修改放到最前头。比如你对主branch进行rebase以后, 你的所有修改就会在主branch当前所有的修改之前。你会更有信心保证你的代码运行畅通无阻。通过你自己的测试以后, 你就可以放心的把代码合并到主的branch里面了。

这里值得一提的是，rebase通常是发生在自己的个人branch上的。它的基础就是现有的主branch。这样做的好处就是保证每个人的代码都可以运行在当前最新的主branch的代码上。

这里再提一个比较有意思的现象。在我工作的这么多公司之中，只有不多的几家在使用rebase, 有相当数量的公司还在使用merge。经过观察我发现, 凡是代码管理混乱的项目， 或者整个项目组的做决定者不太清楚代码整洁的重要性， 或者脑子有问题的， 他们都在使用merge。哈哈，我开玩笑呢。

不过， 我还是建议大家去亲身体验一下rebase的好处吧。

好了，这期就先说这些，这里是丁哥开讲，欢迎关注防止失联。