git重基和git合并的主要区别

Question

在网上搜索了很多之后，我知道这个问题已经被详细讨论过了。我想我现在明白了。但我想确认一下，如果使用git-rebase Vs git-merge的主要区别是与git-rebase的线性/干净历史，而不是git-merge的可处理性？或者，如果我们总是使用git-merge，那么团队还会错过什么吗？

还有人建议，如果团队不知道rebase的复杂性，那么就使用merge

Answer 1

有许多项目需要考虑。我不确定这会是一个完整的列表(“完整”很难)。

1. 合并在概念上很简单，但却充满了棘手的问题。为了更好地理解它，您必须了解Git的提交图是如何工作的。 每个合并有几个部分：

换句话说，如果只有一个L或R影响F，则采取L或R版本批发。否则，将更改组合起来。如果这些更改中有任何冲突，请声明合并冲突。对两个更改集中的所有文件重复，并保持所有未修改的文件与基本文件相同。

结果是组合的一组更改，只要没有冲突，Git现在就可以进行新的提交。新提交可以是合并提交，即记录双亲L和R，以便提交图记录合并行为。这是正常(真实)合并的正常情况。

除此之外，Git还有它所称的快速转发合并(根本不是合并)，也有压缩合并(完成合并更改的合并工作，但随后进行普通的、非合并提交)。这意味着，除了merge本身在概念上是简单的(但是有上述所有的角大小写问题)，您需要认识到Git既有合并为动词的意思，也就是这种变化集组合的事物，以及合并为名词，其中“合并”的意思是“合并提交”：记录其双亲的提交。

1. 在你理解重新基地之前，你需要了解樱桃采摘。这还需要了解Git的提交图是如何工作的。每个樱桃选择通过计算提交快照中的更改集来复制提交。更改集只是提交的父级与提交本身的区别(“此提交中更改了什么？”)。然后，Git将此更改--设置为其他提交，使用相同的合并进程--合并作为动词--用于git merge。樱桃花的合并库有点让人困惑，但在实践中，这主要是可行的。
2. 重基包括自动挑选一些提交到复制，然后是一个分支标签的运动，以放弃原来(预复制)提交，以支持新的(复制)提交。 因此，要正确理解重基，您需要理解樱桃挑选，这意味着您需要了解合并。您还需要了解Git的分支标签是如何工作的，要理解git reset和git branch -f，需要了解这一点，以及强制推送意味着什么。要理解Git选择如何复制提交集，您需要了解Git的提交图--但您需要这样做才能了解git merge如何找到合并基，所以尽管这看起来很困难和/或可怕，但到目前为止您已经知道了这一点。

最后，这并不是很难:只有几个非常大的图论相关的障碍，你必须几乎同时清除。但是，不可否认的是，git rebase比git merge更复杂，这只是因为git rebase通过git cherry-pick使用了git merge的大部分内容。

由于重基副本提交(然后放弃原始副本以支持新副本)，通常最好避免在人们可能关心原始提交的散列ID的地方这样做。(提交是由其散列ID唯一标识的。)作为一条捷径，您可以使用一个非常简单的概念:如果提交未发布，只有您知道它的散列ID，因此没有其他人可能会关心它的散列ID。

在一个典型的设置中，这意味着如果您没有使用git push来发布您的提交，那么在它们上使用git rebase是安全的；但是如果您使用了git push，它就不那么安全了:现在所有拥有它们的人(因为您推动了它们)都必须知道如何处理复制和放弃的事情。