我有一个具有以下提交历史的文件：
$git log --oneline
49740e5 3: Third version
796a330 2: Second version
539aa76 1: First version
647d060 file C creation
在每个版本中，我只是在文件中添加了一个文本字符串。我想如果我恢复"；796a330 2：第二版本"；git将自动生成一个revert提交我会得到这样的东西：
3: Third version
1: First version
file C creation
但实际上，这个动作并不是自动的，我有一个合并冲突需要解决。为什么？
使用git revert 796a330，796a330 2不会从日志中消失。相反，创建了另一个提交，它试图将796a330 2的反向补丁应用到49740e5 3上。
关于冲突，这里有一个例子。假设在539a76 1中，C为空。然后，在796a330 2中，添加了一行hellon。然后在49740e5 3中，该行被替换为worldn。
CCD_ 11的补丁从零到CCD_ 12，CCD_ 13的补丁从CCD_ 14到worldn。CCD_ 16的反向补丁是从CCD_。当反向贴片要应用到49740e5 3上时，它在C中找不到hellon，因为C只有worldn。因此，它报告了冲突。
换句话说，49740e5 3的变化取决于796a330 2的变化。如果要在不发生冲突的情况下恢复796a330 2的更改，则需要先恢复49740e5 3。如果这两组更改是独立的，那么git revert 796a330在这种情况下不会引起冲突。
冲突不是错误。你可以通过保留你想要的代码和删除你不想要的代码来解决它们。冲突的标记应始终删除。
从技术上讲，它使用的机器与用于合并的机器相同，只是它没有使用a late "common" ancestor作为合并2个分支的基础，而是使用您要求恢复的修订作为合并的基础和该修订的父级，就像它是the other branch一样。消息是一个模板，讨论正在恢复的内容。。。。。然后，当然，冲突有一个不同的"；意思是"；来自合并。
http://ezconflict.com/en/conflictsse12.html#x53-890001.7
完全披露：我的材料(没有货币化，没有cookie，没有跟踪(
git revert命令实际上是通过向分支的HEAD添加一个新的提交来实现的，该提交在功能上取消了您向其提及的任何提交。因此，调用git revert后的历史记录实际上如下所示：
$ git log --oneline
abcdefg revert 796a330
49740e5 3: Third version
796a330 2: Second version
539aa76 1: First version
647d060 file C creation
现在，您的分支应该表现得好像从未进行过796a330提交一样。使用这种方法恢复提交的一个原因是，它避免了重写您的历史记录。请注意，也可以使用交互式rebase之类的东西来删除/删除796a330提交。但是，这将再次强制推送您的分支，这反过来可能会给其他已经签出并使用具有旧历史的分支版本的人带来问题。