'git merge'如何搞乱你的提交历史？
考虑由几个同时在代码库上工作的开发人员组成的团队。 当功能重新回到主分支时，可以使用git merge或git rebase 。
我从其他几位开发人员那里听说过，与git rebase相比，如何使用git merge将会使你的git历史变得很古怪。
我也看到了关于合并和rebase之间的区别的问题。
其中一个回答提到rebase的优点是避免了钻石形状。 但是这对于git日志意味着什么呢？
另一个SO回答谈论如何合并交织历史的线程。 但是，对于主要分支来说，拥有它所包含的所有作品的所有历史是否可取？
我想我的一般问题是 ：在使用merge和rebase时如何生成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
结论
真的有很多话要说（例如在rebase示例中，可以避免合并提交，但是会丢失日志中的分支布局）。
对我来说主要的区别在于，通过rebase，功能分支与master和其他分支合并为master。
既然你不是在征求意见，我把它留给你。
链接地址: http://www.djcxy.com/p/45107.html