我们有一个名为6 个月前upgrade分支的分支。master在upgrade分支中我们将所有项目重组为maven（master是ant项目），所以两个分支中的一个项目x的结构是完全不同的。
为了将项目重组为我们使用的 Maven，git mv因此我们保留了历史。接下来，我们对文件进行了一些代码更改，upgrade因为升级过程需要这些更改。
现在我想合并master，upgrade同时保留所有结构，因为它存在于upgrade. 我该怎么做呢？
我尝试git merge master在upgrade树枝上使用。
但这并没有让我对我们所做的代码更改产生任何冲突upgrade；相反，它给了我属性文件中的冲突。（我绝对确定与upgrade冲突的代码更改master） - 可能有什么问题？
您想要的是使用该ours策略（而不是该答案的先前版本中提到的策略选项）；开启时upgrade，使用git merge -s ours master. 根据git merge 手册页中更详细的信息，这根本不会尝试进行实际的合并，而只是使用ours一侧的树作为结果并丢弃合并中的每一侧。
使用合并将保留所有历史记录，创建合并提交（显示历史记录中两个分支的融合），但使用合并一侧的所有文件。
请注意，“我们的”和“他们的”的含义仅取决于您在启动合并时所处的分支（“将升级合并到主控”与“将主控合并到升级”，两者都会产生相同的结果历史） . “我们的”是您站在的一个分支，“他们的”是/是您在merge命令中指定的分支。手册页中对此进行了详细说明。
编辑：作为解释：您（很可能）在您所做的代码更改上没有遇到任何冲突，因为 master 与通用代码库没有足够的差异。默认情况下，git merge使用三向合并策略，该策略采用要合并的两侧的最新共同祖先，并且仅实际查看相对于该共同祖先的更改。如果只有分支的一侧取得进展，Git 将识别那里的所有更改都会取代旧代码（在您的情况下，代码 on master），并且它只会upgrade自动使用代码（即它自动解决“冲突”）。
只有当合并的双方与共同祖先相比都发生了变化时，才会提出您必须手动解决的冲突。在这种情况下，Git 不知道哪一方“更好”——甚至可能需要将这两个方面结合起来才能工作。这就是要求用户解决此类冲突的原因。
注意：答案已更新，因为我之前误解了 -s 和 -X 选项。