我们正在运行GitLab作为我们的中心Git仓库，并在本地使用TortoiseGit以及VS2010 SP1作为我们的主IDE，开发ASP.NET应用程序。我们在2个月前从TFVC过渡到GIT，我们仍然是新手。我们分支修复了每个错误，现在我们只使用no-ff合并。
我们正在开发一个新的功能分支，而且除了我自己以外，还有4个开发人员正在开发它。上周我们发现一些合并到这个功能分支的生产错误修复被一个开发人员（dev-A）覆盖。经过调查，我们怀疑dev-A可能在其本地仓库中提交了旧版本的代码，然后将其推送到服务器。我们无法找到他所做的确切事情，因为他不确定自己，这发生在3周前。
当我们检查日志和GitLab中的提交网络时，似乎有两行在一行上，dev-A在本地提交了冲突的代码，并在2周后推送到服务器之前继续工作，另一行维护团队合并上一次生产错误修复的行。当dev-A从服务器拉出并合并并发生第一次冲突时，该线会聚。我协助他并注意到大量的冲突，但我认为这是正常的，尽管冲突根本不是冲突，即0行与几行代码。之后，当下一个开发人员（dev-B）从服务器拉取以获取最新代码时，同一冲突中会出现相同的文件列表。这是我们开始怀疑的时候。我们的初步调查还发现，一些错误修复实际上已被逆转。
我们现在让每个人都去他们自己的分支机构（功能名称），而我们尝试访问这种情况。当我们拉/合并/推动时，我们担心冲突会不断变化。我想知道我们是否需要回到历史中删除那个特定的违规提交，但我们希望保留剩余的有用历史记录。任何调查和前进的指示都会有所帮助。
感谢并且对于冗长的解释感到抱歉。
答案 0 :(得分：2)
根据我的经验，我可以猜测，混乱来自使用TortoiseGit，在我的情况下，它是一个SourceTree，在冲突解决后提交。流程大致如下：
git rm --cached <file>，这意味着，从索引中删除文件。作为步骤3的结果，未经检查/删除的文件将重置为开发人员的本地副本，并且远程更改已经消失。
为了防止将来发生这种情况，请指导您的开发人员不要干预merge进程，除了编辑和添加索引有冲突的文件。
我认为找到解决冲突的所有可能合并的良好起点将是git log --merges --grep "Conflict"。
祝你好运!!!
答案 1 :(得分：0)
经过进一步调查后，我们怀疑dev-A粘贴在TFS过渡期间保存的文件夹的旧副本上，因此一堆较旧的文件被提交为新的更改，导致冲突和最新错误修复的逆转。
我们后来发现我们可以通过UI实际提交另一个用户并使用自定义时间戳，因此我们选择创建一个新的功能分支，＆＃34;重播＆＃34;所有来自dev-A的提交减去违规的提交，并从现有的第二行更新中拉出/合并，从dev-B重新定义最新的更改，然后重命名现有的功能分支并将此新分支推送到服务器，然后让所有人结账新的分支机构覆盖了他们的本地仓库。
现在似乎没事。我们让大多数开发人员检查他们的代码，并将保留旧分支一段时间，以防万一。接下来的目标是为所有开发人员制定更严格的指南。