git在后台合并了什么？
我知道$ git rebase在后台做什么。 假设：
A -- B -- C
D -- E
$ git rebase会记住我们在e （base是b ）中所做的所有更改并将它们应用于base c 。 结果是：
A -- B -- C -- D' -- E'
现在我想知道， $ git merge在背景中做了些什么？ 其实有趣的部分是“为什么合并有冲突的可能性，但是基础不变”？
为避免冲突，在合并之前使用rebase
确实如此：为避免发生冲突，必须将分支合并到上游分支（例如推送时）：从模式中，合并将是一个快速向前的分支。
此外，您可以训练重新组合来记住您可能需要做的冲突解决方案，这意味着您可以重新组合多次，而无需重新解决所有相同的冲突。 请参阅git rerere （即使您最初没有激活rerere，也可以进行手动再训练）。
这就是为什么我推荐pull --rebase （ pull --rebase ）之前推（也在这个答案）：你解决可能的合并冲突本地（在你的本地回购），在推回你的本地提交之前。
但请不要误会，一个rebase会使用合并策略重新应用您在另一个分支之上的每个提交。 因此合并冲突可能会发生。
这将在Git 2.14中更好地表达。
冲突与提交以及树对比无关。
如果您在分支1中对文件A，B和C进行了一些更改，则隐藏您的更改并移至分支2，其中B的内容不同，您将在文件B中发生冲突。尽管您未提交任何提交任何。
以不同方式合并和重组工作。 合并和rebase之间最基本的区别之一是合并提交具有多个父提交 - 如果您曾想要从合并提交返回，则必须指定父代号。
合并提交的方式是，如果要合并的分支具有4个提交，则合并提交将在主分支的顶部进行，并且所做的更改等于4次提交更改的总和（类似于当你挤压提交时你会得到）。 如果您遇到冲突，您可以立即获得所有变更的所有冲突。
重新定价是不同的 - 更改是应用提交承诺。 如果在提交2中存在冲突，则必须在应用3之前解决它们。 提交的ID也被改变，以表明这些是重新提交的提交。
链接地址: http://www.djcxy.com/p/45111.html