git revert操作引起的代码丢失以及解决方案

场景如下：

1. 某项目下有很多开发中的分支，比如分支a，b，c，d都合并到了一个test分支上；
2. 某次误操作将test分支内容合到了分支e上，然后紧接着又revert了这次合并，试图撤销合并；
3. 接着将分支e合并master上线；
4. 过了若干天，将master再合并到a，b，c，d分支上时，发现之前修改的代码被合并丢掉了。

这时候你会纳闷，为什么代码会丢掉，关于git revert的操作解释如下：

• 创建一个新的提交：当你对某个提交（或一系列提交）执行 git revert 时，Git 会创建一个新的提交，这个新提交包含了对指定提交所做更改的“逆操作”。换句话说，它尝试将指定提交中的所有更改都“撤销”掉。
• 保留原始提交：与 git reset 或 git rebase 不同，git revert 不会修改或删除原始提交。原始提交仍然保留在 Git 历史中，但新提交的更改会撤销它的效果。
• 保持历史的线性（如果可能）：默认情况下，git revert 会尝试在当前分支的顶部创建一个新的提交来撤销指定提交。这有助于保持历史记录的线性，尤其是在与远程仓库共享代码时。然而，如果指定的提交不是当前分支历史的一部分（例如，如果你试图从一个分支上撤销另一个不相关分支的提交），你可能需要使用额外的选项（如 --mainline）来确保正确的行为。
• 处理合并冲突：如果撤销的提交与当前分支的更改有冲突，git revert 会停止并让你手动解决这些冲突。解决冲突后，你需要像处理任何其他合并冲突一样提交结果。
• 影响未来的合并：由于 git revert 创建了一个新的提交来撤销原始提交的效果，这会影响未来的合并操作。如果将来某个分支（如 master）再次合并包含原始提交的分支（如 a, b, c, d），那么合并将包括原始提交和新的撤销提交。然而，由于撤销提交的存在，原始提交的效果将被抵消，因此在合并后的结果中不会看到这些更改。
• 对公共仓库的影响：如果你已经将包含原始提交的更改推送到了公共仓库，并且想要撤销这些更改，你需要首先在你的本地仓库中执行 git revert，然后将包含新撤销提交的更改推送到远程仓库。这将确保所有与你有共享历史的协作者都能看到并接收到你的撤销操作。

总结：git revert确实可以撤销合并，但是会保留撤销的记录，再去合并相关分支时，就会出现代码丢失的情况！

解决方案：

1. 最笨的办法，记住你分支的每次修改记录，手动补上这些代码，慢而且可能漏代码
2. git reset到上述误操作2之前的一次提交记录，将这几天的合并master操作再重新操作一次，适用于后续合并master操作不多的情况
3. 另辟蹊径将a、b、c、d、e的撤销的代码以简单快速并且完整的方式保留。

以a分支举例，当前在a分支，合并master后发现部分代码丢失，操作如下：

（1）先撤销合并master

git reflog

找到merge或者rebase的前一个节点

git reset --hard<commit_hash>

(2) 找到你分支a创建前的一次提交点，并以此提交点创建新分支，

git log
# 找到提交hash，以此提交点新建分支git branch 新分支名 提交哈希值

比较分支a，将a分支原本的全部修改记录，使用git cherry-pick操作拉到【新分支】上
（3）将master分支merge到新分支上
这样操作快速方便也不怕代码丢失，如果不放心可以最后再比较下master分支，看看差异化的是否为原分支a的修改记录

如果您对技术有兴趣，友好交流，可以加v进技术群一起沟通，v:zzs1067632338，备注csdn即可