本帖最后由 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 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。
总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。
| 
|Archiver|手机版|小黑屋|firemail
( 粤ICP备15085507号-1 )
发表于 2017-3-17 17:45:11
