git merge和git rebase的区别, 切记：永远用rebase
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了git merge和git rebase的区别, 切记：永远用rebase，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2504字，纯文字阅读大概需要4分钟。
内容图文
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的好处吧。
好了，这期就先说这些，这里是丁哥开讲，欢迎关注防止失联。
内容总结
以上是互联网集市为您收集整理的git merge和git rebase的区别, 切记：永远用rebase全部内容，希望文章能够帮你解决git merge和git rebase的区别, 切记：永远用rebase所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。