git：合并两个分支：什么方向？ [英] git: merge two branches: what direction?
问题描述
我们有以下情况：
A --- B --- C --- ... - - iphone
/
... ---上班--- --- ---主人
在last-working和iPhone之间，有32次提交。在最后工作和主人之间，很多的提交已经完成。
我现在想要的是一个新的分支，我拥有iphone和current大师合并在一起。在稍后的时间，这应该被合并到主人。
首先，我计划做：
git checkout iphone -b iphone31
git merge master
<然后我想，如果这样做会更好：
git checkout master -b iphone31
git合并iphone
现在我想知道。 结果会有什么不同？合并行为会有所不同吗？
我已经尝试了两种方法，正如我所预料的那样， em>很多冲突，因为与master相比，iphone真的很老。现在我想知道将它们合并的最简单方法。
也许甚至以master为开头并将每个单独提交的iphone合并到它中会更容易？就像这样做：
$ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ g $ $ b git merge C
...
git merge iphone
最后，当这个合并完成时（即所有的冲突都解决了并且它正在工作），我想这样做：
git checkout master
git merge iphone31
git checkout iphone -b iphone31
git merge master
和
git checkout master -b iphone31
git merge iphone
它们会有相同的缓解或困难，就像争论一杯是半满还是半空。
版本树感知
我们如何看待版本树在某种程度上只是我们的任意感知。
假设我们有如下的版本树：
A --------- - +
| |
| |
\_ / \_ /
B X
| |
| |
\_ / \_ /
C Y
|
|
\_ /
D
|
|
\_ /
E
假设我们想让根据从C到E的变化，从Y
检出新版本Z，但不包括从
A到C的变更。
哦，那会很困难，因为没有共同的起点。
好吧，不是真的。如果我们只是在图形布局中将对象放在一个不同的
中，像这样
/
C + -------- +
| \ |
| |
\_ / |
D B
| / \
| |
\_ / |
E A
|
|
\_ /
X
|
|
\_ /
Y
现在事情开始看起来很有前景。请注意，我没有在这里更改任何关系船，箭头的位置与前一张图中的
相同，版本A仍然是公共基础。
只有布局被改变。
但现在想象一个不同的树现在是微不足道的
C'--------- +
| |
| |
\_ / \_ /
D B'
| |
| |
\_ / \_ /
E A
|
|
\_ /
X
|
|
\_ /
Y
其中任务只是合并所以你可以合并任何你想要的东西，影响
的唯一一件事就是在
之间完成的改变的总和，即
$ b $您选择$ b作为出发点或共同基地以及您合并到的位置。
您并不仅限于使用您的
版本控制工具所建议的自然起点。
这可能不是一些简单的版本控制系统/工具，
，但如果所有其他的都失败了，
就没有什么能阻止你通过
手动完成此操作，检出版本C并将文件另存为file1，
检出版本E和将文件保存为file2，
检出版本Y并将文件另存为file3，
并运行 kdiff3 -o merge_result file1 file2 file3 。策略会产生这样的结果最少量的问题，但
，如果有许多变化造成某种冲突，它
可能更容易拆分并合并更小的零件。
我的建议是
，因为在last-working和iphone之间有32个提交，
可以通过分支master来实现，然后
在前16次提交中合并。如果事实证明
太麻烦了，请恢复并尝试合并8个第一次提交。
等等。在最糟糕的情况下，您最终将逐个合并32个提交中的每一个
，但它可能比在一个合并操作中处理所有
累积冲突更容易（并且
in那么你正在使用一个真正的分歧代码库）。
提示：
在纸上画一个版本树并用箭头记下你想要
合并的东西。如果您分几步完成流程
，请将它们分离出来。这会让你更清楚地知道你想要什么
来实现，到目前为止你做了什么以及剩下什么。
我真的可以推荐 KDiff3 ，它是一款出色的差异/合并工具。
We have the following situation:
A --- B --- C --- ... --- iphone
/
... --- last-working --- ... --- master
Between last-working and iPhone, 32 commits were made. Between last-working and master, a lot of commits were made.
What I want now is a new branch where I have iphone and current master merged together. And at some later time, this should be merged into the master.
First, I planned to do:
git checkout iphone -b iphone31
git merge master
But then I thought, if it would be better to do:
git checkout master -b iphone31
git merge iphone
Now I am wondering. What would be the difference in the result? Would the merge behave different?
I already tried both and as I have expected, I got many conflicts because iphone is really old compared to master. Now I wonder about the easiest way to merge them.
Maybe even starting with master and merging each single commit of iphone into it would be easier? Like doing this:
git checkout master -b iphone31
git merge A
git merge B
git merge C
...
git merge iphone
At the very end, when this merge is done (i.e. all conflicts are resolved and it is working), I want to do this:
git checkout master
git merge iphone31
Regarding the alternatives
git checkout iphone -b iphone31
git merge master
and
git checkout master -b iphone31
git merge iphone
they will have identical ease or difficulty, it is like arguing whether a glass is half full or half empty.
Version tree perception
How we look at version trees are in some way just our arbitrary perception. Let's say that we have a version tree like the following:
A----------+
| |
| |
\_/ \_/
B X
| |
| |
\_/ \_/
C Y
|
|
\_/
D
|
|
\_/
E
And let's say that we want to make a new version Z checked out from Y based on the changes from C to E but not including the changes made from A to C.
"Oh, that will be difficult because there is no common starting point." Well not really. If we just place the objects a little differently in the graphical layout like this
/
C+---------+
| \ |
| |
\_/ |
D B
| / \
| |
\_/ |
E A
|
|
\_/
X
|
|
\_/
Y
now things are starting to look promising. Notice that I have not changed any relation ships here, the arrows all point the same way as in the previous picture and version A is still the common base. Only the layout is changed.
But it now trivial to imagine a different tree
C'---------+
| |
| |
\_/ \_/
D B'
| |
| |
\_/ \_/
E A
|
|
\_/
X
|
|
\_/
Y
where the task would just be to merge version E normally.
So you can merge anything you want, the only thing that influence the ease or difficulty is the aggregate of changes done between where you select as a starting point or common base and where you merge to. You are not limited to using the natural starting point the your versioning tool suggest.
This might not be simple with some version control systems/tools,
but if all else fails there
is nothing that stops you from doing this manually by
checking out version C and save the file as file1,
checking out version E and save the file as file2,
checking out version Y and save the file as file3,
and run kdiff3 -o merge_result file1 file2 file3.
Answer
Now for your specific situation it is difficult to say exactly what strategy that will produce the least amount of problems, but if there are many changes that create some kind of conflict it probably is easier to split up and merge smaller parts.
My suggestion would be that since there are 32 commits between last-working and iphone, you could for instance start by branching of master and then merge in the first 16 commits. If that turns out to be too much trouble, revert and try to merge the 8 first commits. And so on. In worst case you end up merging each of the 32 commits one by one, but it would probably be easier than having to handle all the accumulated conflicts in one single merge operation (and in that case you are working with a really diverging code base).
Tips:
Draw on paper a version tree and note with arrows what you want to merge. Cross off things as they are done if you split up the process in several steps. This will give you a clearer picture of what you want to achieve, what you have done so far and what is left.
I can really recommend KDiff3, it is an excellent diff/merge tool.
这篇关于git：合并两个分支：什么方向？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
