如何让Git在分支A合并分支B时强制触发合并冲突？

为什么你的操作没触发冲突？ #

你之前的操作看起来绕了一圈，但本质上没改变文件的实际内容——Git判断文件有没有修改，核心是看文件内容的哈希值：只要内容没变，不管你怎么折腾索引，Git都觉得文件没改过。

1. git rm -r --cached "myFolder" 只是把文件夹从Git的索引里移除，本地文件完全没动，这一步提交的是“删除文件夹”的变更，但文件内容还好好存在本地。
2. 接着git add .把文件夹加回索引，这时候文件夹里的文件内容和分支A最初的状态完全一致，所以Git记录的“加回文件夹”的提交，相当于把文件又恢复到了原来的状态。

这么一来，在Git眼里，经过这两次提交后，myFolder的最终内容和分支A基于master的初始版本没有任何区别。而分支B是修改了该文件夹里的文件，合并时Git会对比两个分支相对于共同祖先（master）的变更：A分支里这些文件没变化，B分支里是修改后的内容，所以Git会直接把B的修改合并过来，自然不会产生冲突。

无需修改文件内容触发冲突的方法 #

这里给你两个简单可行的方案：

方案1：修改文件权限（最便捷）

Git会跟踪文件的权限变更，你可以给目标文件添加可执行权限，这样Git会把权限变更当作一个修改提交，和分支B的文件产生差异：

git checkout feature/A
# 给目标文件夹下的所有文件添加可执行权限
chmod +x myFolder/*
# 提交权限变更
git commit -am "modify file permissions to trigger merge conflict"

之后执行git merge origin/feature/B，Git就会因为文件权限的差异触发冲突，你可以在冲突处理阶段选择保留需要的版本。

方案2：先删除文件夹再合并（更直接）

如果你的目标是触发“删除/修改”类型的冲突，可以直接在A分支删除目标文件夹并提交，合并B分支时Git会因为无法自动判断保留删除还是保留修改，从而触发冲突：

git checkout feature/A
# 彻底删除文件夹（本地文件也会删除，如果你想保留可以先备份）
git rm -r myFolder
git commit -am "remove myFolder to trigger merge conflict"
# 执行合并
git merge origin/feature/B

这时候Git会提示冲突，你可以根据需求选择恢复文件夹并合并B的修改，或者保留删除操作。

内容的提问来源于stack exchange，提问作者user9497598