git rebase 是不是就是跟 merge master 到你的 branch 产生代码的效果一样的, 不考虑 history log 等其他的因素

2014-11-02 10:50:25 +08:00
vunlin  vunlin
4202 次点击
所在节点   问与答  问与答
5 条回复
iloahz
iloahz
2014-11-02 11:45:01 +08:00
感觉最终结果应该是差不多的,如果大家对解决冲突的意见统一的话
finian
finian
2014-11-02 12:31:55 +08:00
看你怎么定义「效果」,如果以最终代码是否一样作为判断标准,则效果是一样的(前提是解决冲突的方式一致),但两种方式的 commit history 有很大不同。

merge 的优点是能直观地区分 commit 边界(比如能区分哪一坨 commit 是逻辑相关的,如在一个 feature branch 内)。缺点是 merge 多了 commit history 整个看起来可能会很混乱;rebase 的优点是能使 commit history 看起来更清晰,能整成线性的,看起来如同一个人提交地一般。缺点就是 commit 之间的逻辑相关性被去掉了,看不出边界。还有一点很重要,rebase 会修改 commit history,所以解决冲突时要慎重,搞不好会搞丢代码。

一般建议在开发分支合并到主分支时使用 merge (保留开发分支逻辑边界);开发分支同步主分支更新时使用 rebase (使开发分支 commit history 更清晰)。

之前我们在同步主分支更新时就使用 rebase,由于当时对 SourceTree 的 rebase 解决冲突的 use mine 和 use their 理解有误,导致代码改动丢失了,幸好 IDE 有本地历史可以恢复。后来考虑到 rebase 会修改历史,最后还是采用 merge 的方式了。
julyclyde
julyclyde
2014-11-02 17:30:07 +08:00
@finian lz问的是merge feature branch into master啊。理论上连commit history都应该相同
vunlin
vunlin
2014-11-03 00:18:37 +08:00
@finian 你用merge master 到 分支 branch 来阶段性同步 分支branch 开发吗? 还是等分支好了, 一下子merge 到 master?
finian
finian
2014-11-03 09:52:14 +08:00
@vunlin 看具体情况吧,如果 master 有 branch 需要的东西就阶段性 merge,没有就一次性

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/143329

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX