先说现象：同事在Develop分支上删除了一些文件，我们将自己的特性分支合并到Develop时，不会感知到这些删除操作，所以没有报冲突，而是当做新文件给直接提交了。我们的特性分支是从Uat分支签出来的，按道理说这种现象应该不存在。
具体分析的时候，发现如下情况：
- A同事将删除了文件的分支合并到了Develop分支，解决了冲突，并提交了代码。
- B同事将自己的特性分支合并到了Uat，解决了冲突，并提交代码，进行发布进行功能验证
- B同事将自己在Uat已经验证的分支合并到了Develoop、Sit分支，这个时候没有保任何冲突，同事直接提交
- C同事（也就是我）拉Develop最新的分支，合并自己的特性分支，这个时候没有报任何冲突，同事直接提交
事情发生的根源在于B同事将Uat分支合并到Develop时的操作，但是此时，Git也并没有报任何冲突。我目前猜想的原因时，Uat分支已经和Develop分支失去了同步，也就是Develop分支和Uat分支只是某个父节点有关系，而两个分支的Head之间没有任何关系，所以Uat合并到Develop时，被视为了一次极其普通的合并。
额，其实我们项目分支管理挺乱的，我们虽然有规范，但是没有专门的人负责这块，约束这些东西，所以大家都是按照自己的理解在处理问题。
简单实验设计
- master分支：a.txt
- child1 from master分支：delete a.txt
- child2 from master分支：change a.txt
- 合并child1分支到master
- 合并child2分支到master
合并时报冲突，提示a.txt被删除，所以，如果操作正确，Git肯定是会发现删除冲突的。
解决问题时的思路
-
需要先确保是不是因为Git没有删除冲突的提示，导致我在合并代码时直接合并了。用了上面的小实验，发现Git会进行提示。
-
需要知道是不是删除操作有什么问题，导致跟踪丢失。我用了下面的指令进行查看，发现只要是删除的文件，都查不出来，所以从这个角度解决问题，没有太大的意义。
git ls-tree -r master --name-only
-
对比是否是因为Git命令行没有提示，而Idea的仓库管理工具会提示（同事认为是这样的），经过实验，发现两者的表现是一样的。
-
用git checkout COMMIT_ID直接到某次提交，然后用git merge COMMIT_ID，去复现开发时的操作，看没有提示。（这种操作拓展了我解决问题的思路，也正是这个操作让我发现了问题所在）