我有一个合并冲突，我不知道如何处理，这是场景。
我有 Alpha 和 Gamma 。
Alpha看起来像是因为Thing.js已被删除
Folder
|___Thing.html
|___Thing.css
beta看起来像这样
Gamma看起来像这样，因为Thing.html和Thing.css被删除了
Folder
|___Thing.js
我想将它们合并到Gamma会给我这个：
Folder
|___Thing.html
|___Thing.css
|___Thing.js
相反，它似乎删除了Thing.js并更新了Thing.html和Thing.css。
我一直在谷歌搜索半小时试图得到一个简明的理由，为什么会发生这种情况以及如何解决这个问题，而我正在空洞中。有没有人有类似的经历，如果是这样你怎么解决它？为什么会这样？
答案 0 :(得分：1)
一个hack是合并如何来获得分支。然后从先前的提交中获取所需的文件。复制/修改/删除文件以获得您想要的情况（必要时添加）并再次提交。
为什么行为本来就是这样？
.js文件在Alpha中被删除，并且在以后的提交中没有被修改，所以它应该被删除。 其他两个文件已在测试版中删除。你写道，他们在伽玛中更新？我假设一个与beta并行的修改导致合并冲突（可能是alpha中的换行符？）。由于两个平行且不兼容的修改。
答案 1 :(得分：1)
我认为你在想：
git merge blah
blah /当前分支相比，查看HEAD。
没有。
git merge做什么 - 至少对于正常的合并情况 - 是在当前分支（即HEAD）和指定的提交之间找到合并基础 blah：
C--D--E <-- curbranch (HEAD)
/
...--o--o--B
\
F--G--H--I <-- blah
合并基础大致是两个分支在我们追溯历史时聚集在一起的地方。
上面的每个大写字母代表一个提交（具有大丑陋哈希ID的东西，它保存了源快照）。 Git现在确实如此：
git diff --find-renames B E # what we did
git diff --find-renames B I # what they did
这些是更改（或更改集）。第一个展示了我们做了什么，从我们与他们共享的提交B开始，跳过所有中间步骤，看看它到底是怎么回事。
第二个显示他们所做的事情，从相同的起点开始。和我们的分支一样，Git会跳过所有中间提交;只有最终的结果是“有趣的”。
Git然后结合两组更改。如果我们删除了两个文件，并且删除了这两个文件中的一个加上第三个文件，则合并后的结果是“删除所有三个文件”。
如果您不想删除文件，可以运行：
git merge --no-commit
避免提交最终结果。然后，您可以git checkout来自提交B的特定文件（您需要自己找到此特定情况）：
git checkout <hash-of-B> <path>
当您按照希望合并结果的方式排列源时，运行git commit。但请注意：这会创建人们称之为邪恶合并的内容。也就是说，它是一个合并结果，与合并的输入不同。
另一种方法是创建至少一个新提交（添加到curbranch或blah，或者甚至在新分支上）放回应该是的文件放回去，准备合并。如果两个分支提示都删除了应保留的文件，则需要对两个分支（或两个新分支）执行此操作。
现在，您可以使用相同的合并基础B将新提交与其他提交或其他新合并提交合并。现在两个输入不会删除文件，因此合并结果将包含文件。
答案 2 :(得分：1)
我想你会想象伽玛会以某种方式看待，因为你认为合并是一种合并内容。但事实并非如此。合并结合了变化。
删除文件是一种变化。在分支上，如果删除文件并提交更改，则表示要git“实现为其创建此分支的功能，我需要删除此文件”。几乎总是这样的情况，你将合并它的“另一面”没有也删除文件;因此，为了使您的案例按照您想象的方式处理，这意味着几乎每次删除文件的尝试都会在下次合并时撤消。大多数用户会发现相当令人不安。
所以相反，你做合并，git说“好吧，在这方面完成工作。必须删除js;但是为了完成工作，必须修改工作。我必须修改。我我不打算猜测如何解决这个问题，因此进行合并的用户必须告诉我。“这是一场冲突。
我越来越多地看到人们想要创建分支的工作流，然后从该分支中删除他们不打算在该分支中工作的所有文件。以上是这些工作流程100％错误的原因。如果你必须有稀疏的工作树，你可以使用稀疏结账;但是如果您删除了这些文件，那么您将在合并中获得不需要的结果。
如果合并的“另一面”修改了文件，那么你会比较幸运，因为你会遇到冲突，你可以通过从没有删除文件的分支获取版本来解决冲突。如果没有冲突，则会以静默方式删除该文件。