'git merge'如何搞乱你的提交历史？

考虑一个由若干开发人员组成的团队，他们同时在一个代码库上工作。将功能恢复到主分支时，可以使用git merge或git rebase。'git merge'如何搞乱你的提交历史？

我从其他几位开发者那里听说过，与git rebase相比，如何使用git merge将使您的git历史变得时髦。

我也看到了这个SO question about the difference between merge and rebase。

One SO answer提到rebase的优点是如何避免钻石形状。但是这对于git日志意味着什么呢？

Another SO answer谈论如何合并交织历史的线程。但是，对于主要分支来说，拥有它所包含的所有作品的所有历史是否可取？

我想我的一般问题是： 在日志如何git的差异使用合并与重订时，会产生什么？

额外信贷：合并使事情变得非常困难的一个例子，而重新贷款会减轻这种困难。

来源

2017-08-02 Cumulo Nimbus

在存储库中运行'git log --oneline --graph --decorate '或'gitk '，您可以看到历史图。如果有许多“合并提交”的消息显示“合并...”，则会看到许多分行并合的行。这就是'git merge'的作用。如果历史严格按照'git rebase'来维护，历史只是一条线。两者都有自己的好坏。 – ElpieKay

你能详细说明为什么'git merge'搞乱了提交历史吗？对于您的情况，我建议您使用'git merge'，原因如下：1.如果所有开发人员将他们的功能分支重新定位为主人，则对主人的提交将急剧增加，并且跟踪历史记录无关紧要。 2.使用'git merge'还可以帮助你分别跟踪每个功能分支 –

这里有一个简单的例子来显示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的例子中，我rge commit可以避免，但是会丢失日志中的分支布局）。

对我来说，主要区别在于，使用rebase时，功能分支与master和其他分支合并为master。

既然你不是在征求意见，我把它留给你。

来源

2017-08-02 16:18:34 Francesco

'git merge'如何搞乱你的提交历史？

回答

相关问题