软件开发的同学请进，Git中的rebase和merge到底有什么区别
本帖最后由 Like_6 于 2017-10-29 20:57 编辑用Git的时间不长，学习时感觉没有区别，两者的功能都是合并，有冲突都要解决，日志记录也没有区别。
一直用的merge, 一直都没用过rebase，一直没注意这事，上周末，同事叫我把我的分支rebase他的分支，我说merge可以吗?他说不行。一定要rebase. 然后讲了下为什么，但是我没有听明白。
请问一下大家，merge和rebase的区别到底是什么呀? 我今天上网找了资料，也在家又一次做了试验，但还是没发现两者的区别。谢谢。
另: Git的GUI工具较多，我用的是TortoiseGit， 不会是因为我选用的工具无法显示这两者的区别吧。
master (带 x1 修改)创建feature分支 (这时候这个feature分支等同于带x1的master)
然后 master 有了x2修改, feature 上面新增加了f1 修改
看起来就是 master x1, x2,然后feature有 x1, f1
feature把新的master合并,就是merge过来,那么feature上面的commit就是x1,x2,f1,当然也可能是 x1,f1,x2,看x2和f1提交的时间而定,如果x2和f1有修改到同一个文件重叠的部分,那就是有冲突,需要处理.
feature对新的master做rebase,那么feature分支上面一定就是x1,x2,f1这个顺序,当然如果有冲突还是要处理.
不同的地方是,如果master上面发生了回滚,就是从x1,x2变成了只有x1,但是,一个feature上面如果对master进行了合并,含有原来的x2提交的话,那么这个feature合并回master以后,这个x2就回去了,就是说master上再次包含了x2,这当然是不希望出现的情况.
如果这个分支是进行的rebase那么feature合并回去,master就是x1,f1的状态,x2不会被再写回去.
所以你同事叫你一定要rebase.背后的原则就是,不同的分支原则上必须是不相关的,只应该相对于master分支做新的提交,分支不应该覆盖包含其他的分支的提交.
我们有个it群,有兴趣你可以加进来. 取决于你们两个的工作的关联，他的是master 分支还是另一个feature，从描述上我猜你的分支应该是feature。(虽然可能性不大)如果你的分支是master，那不允许你rebase他，只能merge他。
如果你是feature，他是master，建议你rebase，这样可以有一个比较清爽的提交历史，而且既然他已经是提交了的master，你作为未来后提交的，rebase可以看到一个单一提交树而不是一个不明所以的merge记录；
如果你们都是feature就比较特殊，一般只有在两个关联feature而且需要联合测试的时候这么干，否则应该是他测试完成以后merge回master你再rebase master。如果是以上的情况，他这样做对他来说提交记录比较完整，如果和你的开发有冲突，需要在你的提交上解决conflict，对你来说稍微吃亏一点，但至少整个历史比较完整。
感谢两位，现在清楚多了。 gaokx 发表于 2017-10-29 21:07
master (带 x1 修改)创建feature分支 (这时候这个feature分支等同于带x1的master)
然后 master 有 ...
请问你们的IT群是微信么?有没有号呢?求拉。
页:
[1]