我们正在从SVN迁移，并且还合并了一堆分支。为了大规模简化，我们有一个很久以前分叉的分支B，并且有一点点开发，假设有8个文件被修改，数百个。与此同时，大师发生了巨大的变化：
A
|
X---(a few changes)--- B
|
|(hundreds of changes)
|
HEAD/master
如果我从分支执行“git merge master”，则会显示许多合并冲突，因为B和HEAD现在非常不同。但这似乎（天真地，对我来说）是错误的：B离行李箱不远，它只是很久以前的时间。
有没有办法利用这个事实？我应该先尝试将B合并回X，然后再从那里合并到HEAD吗？命令是什么：
在这些情况下，人们会使用另一种方法吗？
（很可能我在前面说了一些非常愚蠢和不像git的东西 - 随意指出它们。:)）
答案 0 :(得分：2)
从B和master分叉然后将B合并到X的点创建一个新的分支“X”对你没有帮助。这只是一个快速合并;对于由B合并到主服务器引起的冲突，会有字面上的无变化。您唯一的选择是执行B合并到主服务器并解决冲突。冲突就是它们，并且没有办法“围绕”它们。
答案 1 :(得分：1)
如果它足够糟糕，您可能只想手动重写针对HEAD或至少更新版本的补丁。这不仅有助于解决冲突，还可以为您留下您可能更喜欢的历史记录，还可以帮助您避免不是合并冲突的一部分。由于代码在更改下发生变化，因此存在很多潜在的问题，而且并非所有问题实际上都表现为合并冲突。
也就是说，如果你想尝试以合并的方式完成它，那么你将不得不以这种或那种方式处理这些冲突。它可能可能你可以通过逐步增加来为自己带来一些痛苦，以较小的增量向前迈进。我可以通过逐步改变分支前进来做到这一点：
git rebase version-2 old-branch
# deal with conflicts if they happen
git rebase version-3 old-branch
# and so on...
# until old-branch is based on a recent version
git checkout master
git merge old-branch
这样可以有效地让您在每一步中处理较小的更改，而不是一次处理所有更改。