Git进阶（十九）：git revert 导致 merge 代码丢失问题修复 ...

一、媒介

项目开辟阶段使用分支是feature_xxx，将feature_xxx分支merge到master之后，这时发现刚代码有bug，需要回版本回退，点击revert按钮。
将当地的原分支feature_xxx代码修改后提交到远程分支，发起 Merge 到 Master 的申请会发现，feature_xxx分支和 master 分支的差异 commit 只有 feature_xxx 分支 revert 后的提交记录，之前的代码变动都没有了。
二、问题分析

对于master而言，已经合并过feature_xxx，master包罗feature_xxx的commitid，这些提交不会参与diff，以是不会显示出两个分支的差异。
revert 操作现实是只是举行了一次逆向 commit，将 merge 的代码举行回滚，但是 commit 的记录还存在。也就是说，feature_xxx 上面存在的待提交接码，实在已经是 master 的已往代码，属于已提交过的状态，以是不会显示 different。

三、解决方案

3.1 方案一：官方保举方法

该焦点思想就是：对 revert 的那次提交记录再次 revert 。这个操作能够将本要提交的代码，放置到最新的HEAD，其commitid要比master高，以是会重新diff。
起首，切换到 master 分支，并基于 master 分支拉出一个分支 revert_tmp。作为 master 的副本，revert_tmp 的作用就是生存 revert 的提交记录；

1. git checkout master
2. git checkout -b revert_tmp

复制代码

其次，在 master 分支上找到 revert 的那条提交记录的版本号，回滚至之前的版本（版本号可以通过“git log”下令，大概从网页端检察）；

1. git log         # 查询<版本号>，格式，如：f2c3b544166eec612ea6814d6cd19aeef46824f8
2. git revert <版本号>  

复制代码

然后，切换到 feature_xxx 分支上，将 revert_tmp 这个分支 merge 到 feature_xxx 分支上。

1. git checkout feature_xxx
2. git merge revert_tmp
3. git push -f

复制代码

最后，在 feature_xxx 重新提交对 master 的 merge 申请，会发现 revert 之前的代码都回来了。
3.2 方案二：reset 方法

与 revert 差异，采用 git reset 将 head 向后移动到上一次 merge 前的 commit 版本，会扬弃全部的 merge commit 记录（revert 不会扬弃，是逆向 commit），以是，再次合并不会出现记录不显示大概辩论的问题。

1. git reset HEAD^    # 回退所有内容到上一个版本
2. git reset HEAD^^   # 回退所有内容到上上个版本

复制代码

留意⚠️：审慎使用  git reset –hard 参数，它会删除回退点之前的全部信息!
HEAD 说明：

3.3 应用git cherry-pick commit-version

cherry-pick可以把别的分支上的commit一个个抽离出来，合并到指定分支上。用法如下：

1. $ git cherry-pick <commitHash>

复制代码

针对以上问题，起首找到revert前的commitid，应用git cherry-pick commit-version把commit提交一个个找回。
如果在cherry-pick 过程中出现了辩论 ，可以使用git cherry-pick --continue 跳过此版本；如果想中途退出cherry-pick ，可以使用git cherry-pick --abort下令，实行完cherry-pick 后可以使用git cherry-pick --quit 下令。
3.3.1 cherry-pick 应用示例

举例来说，代码堆栈有master和feature两个分支。

如今将提交f应用到master分支。

1. # 切换到 master 分支
2. $ git checkout master
4. # Cherry pick 操作
5. $ git cherry-pick f

复制代码

上面的操作完成以后，代码库就酿成了下面的样子。

从上面可以看到，master分支的末端增加了一个提交f。
git cherry-pick下令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。

1. $ git cherry-pick feature

复制代码

上面代码表示将feature分支的近来一次提交，转移到当前分支。
Cherry pick 支持一次转移多个提交。

1. $ git cherry-pick <HashA> <HashB>

复制代码

上面的下令将 A 和 B 两个提交应用到当前分支。这会在当前分支天生两个对应的新提交。
如果想要转移一系列的连续提交，可以使用下面的简便语法。

1. $ git cherry-pick A..B

复制代码

上面的下令可以转移从 A 到 B 的全部提交。它们必须按照精确的顺序放置：提交 A 必须早于提交 B，否则下令将失败，但不会报错。
留意，使用上面的下令，提交 A 将不会包罗在 Cherry pick 中。如果要包罗提交 A，可以使用下面的语法。

1. $ git cherry-pick A^..B

复制代码

git cherry-pick下令的常用配置项如下。

• -e，--edit
  

打开外部编辑器，编辑提交信息。

• -n，--no-commit
  

只更新工作区和暂存区，不产生新的提交。

• -x
  

在提交信息的末端追加一行(cherry picked from commit …)，方便以后查到这个提交是怎样产生的。

• -s，--signoff
  

在提交信息的末端追加一行操作者的署名，表示是谁举行了这个操作。

• -m parent-number，--mainline parent-number
  

如果原始提交是一个合并节点，来自于两个分支的合并，那么 Cherry pick 默认将失败，由于它不知道应该采用哪个分支的代码变动。
-m配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。

1. $ git cherry-pick -m 1 <commitHash>

复制代码

上面下令表示，Cherry pick 采用提交commitHash来自编号1的父分支的变动。
一般来说，1号父分支是接受变动的分支（the branch being merged into），2号父分支是作为变动泉源的分支（the branch being merged from）。
3.4 git reset 和git revert的区别

git reset是回退到某个版本之前，在这个版本后提交的代码都没有了，git revert 是单纯的打消某次操作，不影响后续的提交记录（但是如果是要打消merge操作，请慎用此下令，由于有大概出现无法再次merge的情况，如果是打消常规的commit 提交，可以使用）。
四、拓展阅读

• 《Git进阶（二）：git revert 用法》
  
• 《Git进阶（十二）：git merge 用法详解》
  
• 《Git进阶（十八）：git rebase详解》
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。