Git:为什么变基会导致冲突而合并却不会? [英] Git: Why does rebase result in conflicts while merge does not?
问题描述
我可能做错了什么，但是谁能向我解释为什么git rebase导致冲突，而git merge(相同分支)却没有呢?
I'm probably not getting something right, but could anyone explain to me why git rebase results in conflicts, while git merge (same branch) does not?
据我所知，git rebase将来自另一个分支的提交放在我在当前分支上进行的提交之前，而git merge接受那些相同的提交并将它们作为补丁应用到我的分支上，对吗? diff是不是不一样，尽管可能相反?不确定为什么用其他提交修补我的分支不是问题，而用我的提交修补其他分支是为什么.
For as far as I know git rebase puts the commits from the other branch before the commits I made on my current branch, while git merge takes those same commits and applies them to my branch as patch, right? Is the diff then not the same, although maybe reversed? Not sure why patching my branch with the other commits is not a problem, while patching the other branch with my commits is.
推荐答案
我看到有时我的问题仍然受到反对.让我为那些不了解当前选择答案的人解释一下，因为我第一次阅读时肯定没有.
I see that sometimes my question is still getting an upvote. Let me explain for those that do not understand the currently chosen answer, because I sure didn't when I read it for the first time.
假设您的分支master具有提交A，B和C.
Let's say you have branch master with commits A, B and C.
然后从提交C中创建一个新分支mybranch.您提交，并得到提交D和E.
Then from commit C you create a new branch mybranch. You commit, and you get commits D and E.
同时，其他人在master上提交了F和G.
In the meantime someone else commits F and G on master.
master然后看起来像这样:A B C F G，而mybranch看起来像这样:A B C D E.
master then looks like this: A B C F G, while mybranch looks like this: A B C D E.
现在您有两种合并策略:
Now you have two merge strategies:
在mybranch上，键入git merge master.它接受您在mybranch-F和G上没有的所有master提交.它首先将F合并到E(最后一次提交的mybranch)上，然后将G合并到F上.
While on mybranch, you type git merge master. It takes all the commits from master that you do not have on mybranch - F and G. It first merges F on top of your E (last commit of mybranch), and then merges G on top of F.
最终结果:A B C D E F G.尽管这些字母的顺序相同，但提交未按时间顺序进行(或可能未完成)，因为实际上F和G是在(或可能已经)在D和
End result: A B C D E F G. Despite these letters being in the same order, the commits were not done (or may not have been done) in chronological order, because actually F and G were (or could have been) done before D and E. You will see a merge commit in this case as well.
在mybranch上，键入git rebase master.它从master中获取您在mybranch-F和G上没有的所有提交，并将它们提交到当前分支的顶部，将其桥接成当前处于<c5>的状态(因为您从master分支，现在获得分支后在master上完成的所有提交).然后，它接受您的第一个提交-D-并将其合并到G上(在master上完成的最后一个提交).然后，它取E并将其放在D的顶部.
While on mybranch, you type git rebase master. It takes all the commits from master that you do not have on mybranch - F and G and places those on top of your current branch, brining it in the state that master is currently in (because you branched from master and now get all commits that were done on master since you branched off). It then takes your first commit - D - and merges it on top of G (last commit that was done on master). Then it takes E and puts it on top of D.
最终结果:A B C F G D E.好像没有分支被master分开，并且master是一项连续的工作，因为您说过我希望我的分支看起来像是被master分开，然后将我的工作放在最前面它".等效于签出master(现在为A B C F G)，创建新分支mybranch，然后添加提交(A B C F G D E).
End result: A B C F G D E. It looks as if no branch was ever split off master, and if master is one continuous work, because you kind of said "I want my branch to look as if it was just split off master and then my work was put on top of it". It is the equivalent of checking out master (now A B C F G), creating a new branch mybranch and then adding your commits (A B C F G D E).
在此不赘述，仅是说将master的F合并在mybranch的E之上可能不会导致冲突，但是合并mybranch的在master的F顶部的D可能.这实际上取决于更改的代码以及是否与先前的提交兼容的更改.两种情况下都可能发生合并冲突.
Without going into details, let's just say that it could be that merging master's F on top of mybranch's E might not result in a conflict, but merging mybranch's D on top of master's F might. It just really depends on which code was changed an if it was a change that is compatible with the previous commit. Merge conflicts may arise in both cases.
这篇关于Git:为什么变基会导致冲突而合并却不会?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
