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

感觉最终结果应该是差不多的，如果大家对解决冲突的意见统一的话

看你怎么定义「效果」，如果以最终代码是否一样作为判断标准，则效果是一样的（前提是解决冲突的方式一致），但两种方式的 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 的方式了。

@finian lz问的是merge feature branch into master啊。理论上连commit history都应该相同

@finian 你用merge master 到 分支 branch 来阶段性同步 分支branch 开发吗？ 还是等分支好了, 一下子merge 到 master?

@vunlin 看具体情况吧，如果 master 有 branch 需要的东西就阶段性 merge，没有就一次性