'git merge'如何弄乱您的提交历史记录?



考虑一个由几个开发人员同时处理代码库的团队。当将功能工作返回到主分支时,可以git mergegit rebase

我从其他几位开发人员那里听说,与git rebase相比,使用git merge将使您的 git 历史变得时髦。

我也看到了这个关于合并和变基之间区别的 SO 问题。

一个SO答案提到变基的优点是避免了钻石形状。但是,就 git 日志而言,这到底意味着什么?

另一个SO答案谈到了合并如何交织历史线索。但是,一个人的主要分支拥有它所包含的所有作品的所有历史不是可取的吗?

我想我的一般问题是使用合并与变基时生成 Git 日志的方式有什么区别?

额外学分:合并使事情变得非常困难的一个例子,而变基会减轻这种困难。

这里有一个简单的例子来显示git log --oneline --graph --decorate --all的差异。

合并后的日志输出

*   e8dc85d Merge other branch into master
|
| * 30a040f (other) edited a.txt on other branch
* | 0bc86a0 edited a.txt on master
|/
* b6c1082 added a.txt

变基和合并后的日志输出

*   1e42180 Merge another branch into master
|
| * 924fe1e (another) edited b.txt on another branch
|/
* dab33be edited b.txt on master
* 0d64167 added b.txt

结论

真的有很多话要说(例如,在变基示例中,可以避免合并提交,但丢失日志中的分支布局(。

对我来说,主要区别在于,使用变基时,功能分支与主分支垂直分离,其他分支合并到主分支中。

既然你不是在征求意见,我就交给你吧。

最新更新