ruochen
V1
2021/07/19阅读:66主题:全栈蓝
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技术、干货知识、热点资讯
作者介绍
ruochen
V1