我来帮你拆解这个问题——这种自动合并时意外删代码的情况，在团队采用类SVN的集中式Git工作流时确实容易踩坑，尤其是搭配Visual Studio 2015/2017的内置Git客户端时，很容易因为工具提示不清晰或者流程漏洞导致问题重复发生。

一、先确定删除代码的核心原因 #

首先你提到合并提交的两个父版本中，一个有目标代码行、一个没有，这说明某个提交已经主动删除了这行代码，而Git的自动合并逻辑会把这个删除判定为“有效变更”——除非两个父版本同时修改了同一行代码产生冲突，否则Git会默认保留“删除”这个操作。具体到你的场景，可能的触发点有这些：

• VS内置Git客户端的误操作：VS 2015/2017的Git工具在处理拉取、合并冲突时，提示不够直观。比如有人拉取远程development分支时，遇到本地和远程的差异，没仔细看提示就直接选择了「接受远程版本」，导致本地的代码被覆盖，之后又把这个覆盖后的版本推送到远程，形成了“缺失代码行的父版本”。后续其他人合并时，Git就会认为这个删除是有意的，自动合并时删掉代码。
• 未提交本地修改就拉取：如果有人在本地修改了代码但没提交，直接拉取远程分支，VS可能会自动执行 stash 或自动合并操作，导致代码丢失却没被察觉，最后推上去的版本就少了那行代码。
• 无意识的代码删除：比如有人在编辑文件时不小心删了代码，提交前没仔细检查改动内容，就直接提交并推送到远程，这个错误提交成为了后续合并的“坏父版本”。

二、如何排查具体原因？ #

你可以通过以下Git命令定位到问题提交：

1. 查找删除代码的提交：用git log的行追踪功能，精准定位哪次提交删掉了目标代码行：

   git log --oneline -L :<目标代码行的大致范围>:<涉事文件名>
   # 示例：git log --oneline -L 50-60:src/Utils.cs
   

   这个命令会列出所有修改过该文件指定行范围的提交，你能快速找到那个删除代码的提交哈希。

2. 查看提交详情：用git show查看该提交的具体改动，确认是误删还是有意删除：

   git show <提交哈希>
   

   同时可以看提交备注，联系提交者确认当时的操作场景——比如是不是用VS拉取时选了错误的冲突处理选项。

三、避免问题重复发生的方案（除手动合并外） #

1. 优化VS Git客户端的设置，减少误操作 #

• 强制启用手动解决冲突：打开VS的「Tools -> Options -> Source Control -> Git Global Settings」，找到合并相关选项，设置为「Prompt for merge strategy」（提示选择合并策略）或「Manual merge」（手动合并），避免工具自动接受某一方版本。
• 默认使用rebase拉取：同样在上述设置中，将Pull行为改为「Rebase local branch on remote」。Rebase会把本地提交放在远程提交之后，避免冗余的合并提交，而且如果有冲突，会逐个提交让你处理，更容易发现代码丢失问题。

2. 规范团队提交流程 #

• 提交前必须拉取+验证：要求所有人在提交代码前，先拉取远程development分支合并到本地，然后仔细检查合并后的所有改动文件（尤其是核心文件），确认没有意外删除再提交。VS的「Git Changes」窗口会列出所有改动，你可以右键文件选择「Compare with Unmodified」来对比差异。
• 推行提交前代码自查：提交前用VS的「Compare」功能，把本地文件和远程origin/development分支的对应文件对比一遍，确保没有无意识的删除或修改。

3. 给远程分支加保护 #

在你的Git服务器（比如GitLab、GitHub或自建服务器）上给development分支设置保护规则：

• 要求推送前必须通过代码审查（至少1人批准），这样误删的代码能在合并前被及时发现。
• 禁止直接强制推送（git push -f），避免有人用强制推送覆盖远程的正确版本。

4. 升级VS版本（可选） #

VS 2015/2017的Git客户端版本较老，对Git的支持不够完善。如果团队有条件，升级到VS 2019或更高版本，新版本的Git工具冲突提示更清晰，操作逻辑更符合Git的原生流程，能减少误操作的概率。

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