我们有一个名为upgrade的分支，该分支是6个月前从master分支出来的。在upgrade分支中，我们将所有项目重组为maven(master是ant项目)，因此两个分支中的项目x的结构完全不同。
为了将项目重组为Maven，我们使用了git mv，因此我们保留了历史记录。接下来，我们对upgrade上的文件进行了一些代码更改，因为升级过程需要这些更改。
现在，我想将master合并为upgrade，同时保留upgrade中存在的所有结构。我该怎么做呢？
我在git merge master分支上时尝试使用upgrade。
但这并没有给我们在upgrade上进行的代码更改带来任何冲突；相反，它使我在属性文件中发生冲突。 (我绝对确定upgrade上的代码更改与master冲突)-可能出什么问题了？
最佳答案
您想要的是使用ours策略(而不是此答案的先前版本中提到的strategy选项)；在使用upgrade时，请使用git merge -s ours master。根据git merge manpage中更详细的信息，这根本不会尝试进行实际的合并，而只是使用ours端的树作为结果，并丢弃合并中的所有其他端。
使用merge with将保留所有历史记录，创建一个合并提交(显示历史记录中两个分支的融合)，但是使用合并一侧的所有文件。
请注意，“我们的”和“他们的”的含义仅取决于您启动合并时所处的分支(“将升级合并到主服务器”与“将主文件合并到升级”，这两者都会产生相同的结果历史记录) 。 “我们的”是您站立的一个分支，“他们的”是您在merge命令上指定的分支。有关更多信息，请参见联机帮助页。
编辑:作为解释的要点:您(很可能)在所做的代码更改中没有任何冲突，因为master并未与通用代码库充分不同。默认情况下，git merge使用三向合并策略，该策略采用要合并的双方的最新共同祖先，并且实际上只查看相对于该共同祖先的更改。如果仅分支的一侧进行了，Git将识别出那里的所有更改都将取代旧代码(在您的情况下为master上的代码)，并且它将仅自动使用upgrade中的代码(即，它自动解决了“冲突” )。
您必须手动解决的冲突只会在合并的两端与公共(public)祖先相比都发生更改时才会出现。在那种情况下，Git不知道哪一方是“更好”的，甚至可能需要将双方结合起来才能发挥作用。这就是为什么要求用户解决此类冲突的原因。
注意:答案已更新，因为我以前误解了-s和-X选项。