我们最近遇到一个问题，即团队成员在将master合并到其功能分支时意外删除了应用于主分支的所有新更改，然后当他们将分支合并到主分支时，所有更改都是然后删除。幸运的是我们很早就抓住了这个，所以这不是什么大不了的事，但仍需要一两天才能完成并确保我们没有失去任何工作。
造成糟糕合并的同事并不确定它是如何发生的，他之前完成了很多合并，他们一切都很好，他记得做合并并在那天完成合并冲突，所以我们我真的不确定它是怎么发生的。他使用TortoiseGit，我们最好的猜测是有一些错误或取消退出所有的更改，但不知何故离开合并头，当他做了下一次提交，他认为只是一个正常的提交它删除了所有的更改。
我做了一些在线阅读，并了解当你做一个合并提交你基本上告诉git“我手动合并这些文件，这是从现在开始使用的存储库的版本”，但是对我来说，这似乎非常危险，所以我想知道是否有一个设置我们可以打开让git在删除文件时与其中一个父母相比产生警告（特别是如果他们没有冲突）。如果没有设置，有没有理由为什么这样的功能无法在git中实现，我是否误解了什么？在我看来，如果在合并中删除一个分支中已更改的文件，那么这将是一个明智的功能。
（最后我会提到，我们意识到这应该是拉动请求审查中的问题，问题是它是一个巨大的公关，这只发生在初步审查之后，所以审稿人开始只是看在个人承诺而不是整个公关视图中，所以它被错过了。如果我们正在研究更大的功能来分解它们，我们已经讨论过将来减少PR的大小，但是我已经讨论了也对一个更技术性的解决方案感兴趣，因为我的团队抱怨如果这种危险的行为可能没有被捕获，可能会远离git）
（另外，我想我真的更喜欢它不仅仅是文件删除，而是任何被删除的更改，所以如果在一个分支中更改了一些块，并且在合并中删除了所有这些块，那么如果没有冲突导致它们被删除，理想情况下会发出警告）
答案 0 :(得分：0)
merge首先可以使用--no-commit选项进行检查，如果结果良好，可以进行最终合并..
使用--no-commit，您可能会收到如下消息。您可以编写其他实用程序，只需grep删除并警告您。
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644
另一个更好的选择是在合并之前识别好，只需跟踪任何提交有任何删除文件..