本帖最后由 linux 于 2017-3-17 17:57 编辑
变基 rebase
整合分支最容易的方法是merge命令,他会把两个分支的最新快照已经两者最近的共同祖先进行三方合并,将合并结果生成一个新的快照并提交。 变基的做法就是将其中一个分支上做的修改在另一个分支上应用,而不进行三方合并。可以使用rebase命令将某个分支上的修改都转移到另一个分支上。 它会首先找到两个分支的最近共同祖先,然后对比当前分支和祖先的历次提交,将相应的修改提取出来,然后将当前分支指向目标分支,最后将之前提取的修改依次应用。 当有多个分支想要合并的时候,可以将两个分支的修改通过变基合并到第三个分支上,这个功能很棒,在多人合作开发时非常有用
变基的风险 不要对在你的仓库外有副本的分支执行变基。
变基操作实质是丢弃一些现有的提交,然后相应的新建一些内容一样的提交。如果已经提交推送,其他人也已经从该仓库拉取并进行了后续操作。此时使用Git rebase命令重新整理提交并推送,其他人将不得不再次的与你的提交进行合并,而且我们还要拉取并合并其他人所做的修改。 原则 只对尚未推送的本地修改执行变基操作,不对已经推送的提交执行变基。
通过merge合并分支: git merge --h
git checkout master(主分支)
$ git merge --no-ff -m "merge with no-ff" experiment(要合并的分支)
Git merge –no-ff 可以保存你之前的分支历史。能够更好的查看 merge历史,以及branch 状态。
git merge 则不会显示 feature,只保留单条分支记录。
通过rebase合并分支:
?
http://www.jianshu.com/p/ce9fefaab751
一般 git pull --rebase 这样用
变基 vs. 合并至此,你已在实战中学习了变基和合并的用法,你一定会想问,到底哪种方式更好。 在回答这个问题之前,让我们退后一步,想讨论一下提交历史到底意味着什么。
有一种观点认为,仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档,本身就有价值,不能乱改。 从这个角度看来,改变提交历史是一种亵渎,你使用_谎言_掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办? 既然事实就是如此,那么这些痕迹就应该被保留下来,让后人能够查阅。
另一种观点则正好相反,他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事,怎么方便后来的读者就怎么写。
现在,让我们回到之前的问题上来,到底合并还是变基好?希望你能明白,这并没有一个简单的答案。 Git 是一个非常强大的工具,它允许你对提交历史做许多事情,但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法,相信你能够根据实际情况作出明智的选择。
总的原则是,只对尚未推送或分享给别人的本地修改执行变基操作清理历史,从不对已推送至别处的提交执行变基操作,这样,你才能享受到两种方式带来的便利。
|