git 还原、恢复、回退

通过git revert来实现线主干代码的回滚。如下命令

  • 对于 merge类型的commit对象,还需要“-m”参数

git revert -m 1? commit-id

  • 对于普通的commtit对象

git revert commit-id

1?问题描述

一个同事不小把自己代码合并 到了master生成C2。但是在该同事还没有回滚之前,又有其他同事合并到master生成了?C3。现在问题是我们想要回滚到C1应该怎么做?

2 解决问题

1、选择git revert还是git reset?

git revert是生成新的commit对象,而git reset是删除commit对象,为了保留记录,使用git revert命令。

2、解决

按时间顺序,依次回滚每一个commit对象,直到自己想要的那个commit对象为准。如下:

  • 回滚C3 ,c3-id是C3对应的那个commit-id

git revert -m? 1? c3-id?

  • 回滚C2。其中c2-id是C2对应的那个commit-id

git? revert? -m? 1? c2-id

3、上面的命令为什么有“-m 1”?

这是因为上面的C2和C3不是普通的commit对象,都是merge生成的commit对象。如下图,如果需要通过git revert回滚M3,那么此时会在M3后面生成一个新的commit节点R,那么这个新节点R是属于M分支(M1->M2->M3->R)还是D分支(D1->D2->D3->R)呢?此时可以通过“-m” 来指定,如果是1,表示的是当前所在的分支,如果是2表示的是另外的分支。

对于上面的问题,由于我们当前分支是master,我们希望revert之后生成的commit也在master这条分支上,所以指定“-m 1”。

这里需要注意的是,如果只是普通的commit 对象,不是merge类型commit对象(由merge产生commit对象),就不需要”-m 1″了

3 问题总结

后续再遇到代码回滚,通过哪些步骤来做呢?这里总结了一些步骤。

1、假设在master上C0后面有C1、C2、C3三次代码提交,此时需要回滚到C0。

2、回滚步骤如下

(1)第一步??切到master代码,使用git log,如下图,获取到每一个commit对象对应的commit-id和commit对象类型(是普通类型还是merge类型)。

commit ee1389bba4bfcaa0ddb850c6e58d1e982fdfcb4d
??Merge:  8397201  7dc873c
??Author:  jie01  <[email protected]>
??Date: Thu Oct  12  20:27:33  2017  +0800
????Merge branch  'fweb_1-0-806_BRANCH'  into master

commit  2f315650dff28e94d654309ed3230c34d32f1000
??Author:  shan03  <[email protected]>
??Date: Tue Oct  17  14:33:16  2017  +0800

commit  7dc873cd34b8bba1fab68635ddf8331ab2babc74
??Merge:  cbaf7d9 d24f133
??Author:  xu01  <[email protected]>
??Date: Thu Oct  12  15:59:13  2017  +0800
????Merge branch  'web_1-0-790_BRANCH'  into financeweb_1-0-806_BRANCH

(2) 第二步??按时间倒序,依次执行”git revert”回滚每一个commit对象

  • 对于 merge类型的commit对象,需要“-m”参数
    git revert -m 1? commit-id
  • 对于普通的commtit对象
    git revert commit-id

所以回滚命令如下

  • 回滚C3,merge类型commit对象,需要-m

git revert? -m 1 ? ee1389bba4bfcaa0ddb850c6e58d1e982fdfcb4d

  • 回滚C2,普通commit对象

git revert? 2f315650dff28e94d654309ed3230c34d32f1000

  • 回滚C1,merge类型commit对象,需要-m

git revert -m 1? 7dc873cd34b8bba1fab68635ddf8331ab2babc74

后续问题

比如说当M3执行了git revet生成RM3,此时在master上又有其他人提交了M4,我们还需要在dev上进行开发D4和D5,如下图

此时怎么合并D5到master的M4

(1)第一步? master合并到D5

因为master执行了git revert撤销操作,所以此时D1和D2的代码会被删除?

  • 在master上执行git revert撤销 RM3
  • 将master合并到dev的D5

(2)第二步 将dev的合并到master

附1 其他方法-通过覆盖方法来实现回滚主干

步骤如下:

  • 第一步 分别拉两份代码。第一份代码上面基于master新建一个分支F1,作为发布分支;第二份代码可以通过git checkout切到自己想要回滚的那个版本上(切到某个commit对象上)。
  • 第二步 删除分支F1对应的代码,把第二份代码拷贝到F1上面,即使用第二份代码覆盖F1的代码。。
  • 第三步??提交F1代码,并合并到master。

附2 git revert和git reset区别

1、git revert 。只是撤销某一次commit的操作,并没有删除commit对象;并且会生成一个新的commit对象。

假设分支为m1->m2->m3。当我们”git revet m2″生成m4,此时在m4里面只是把m2的操作撤销了而已,并没有撤销m2和m3对象。此时分支为“m1->m2->m3->m4”

2、git reset。删除某一个commit之后所有commit提交对象;不会产生新的commit对象。

假设m1->m2->m3,当我们git reset m2,此时并没有生成新的commit对象,并且删除了m2和m3两个commit对象,此时分分支为”m1->m2″

撤销提交

Git 的 revert 命令可以用来撤销提交(commit),对于常规的提交来说,revert 命令十分直观易用,相当于做一次被 revert 的提交的「反操作」并形成一个新的 commit,但是当你需要撤销一个合并(merge)的时候,事情就变得稍微复杂了一些。

Merge Commit
在描述 merge commit 之前,先来简短地描述一下常规的 commit。每当你做了一批操作(增加、修改、或删除)之后,你执行 git commit 便会得到一个常规的 Commit。执行 git show 将会输出详细的增删情况。

Merge commit 则不是这样。每当你使用 git merge 合并两个分支,你将会得到一个新的 merge commit。执行 git show 之后,会有类似的输出:

commit 19b7d40d2ebefb4236a8ab630f89e4afca6e9dbe
Merge: b0ef24a cca45f9
......
其中,Merge 这一行代表的是这个合并 parents,它可以用来表明 merge 操作的线索。

举个例子,通常,我们的稳定代码都在 master 分支,而开发过程使用 dev 分支,当开发完成后,再把 dev 分支 merge 进 master 分支:

a -> b -> c -> f -- g -> h (master)
           \      /
            d -> e  (dev)

上图中,g 是 merge commit,其他的都是常规 commit。g 的两个 parent 分别是 f 和 e。

Revert a Merge Commit
当你使用 git revert 撤销一个 merge commit 时,如果除了 commit 号而不加任何其他参数,git 将会提示错误:

git revert g
error: Commit g is a merge but no -m option was given.
fatal: revert failed
在你合并两个分支并试图撤销时,Git 并不知道你到底需要保留哪一个分支上所做的修改。从 Git 的角度来看,master 分支和 dev 在地位上是完全平等的,只是在 workflow 中,master 被人为约定成了「主分支」。

于是 Git 需要你通过 m 或 mainline 参数来指定「主线」。merge commit 的 parents 一定是在两个不同的线索上,因此可以通过 parent 来表示「主线」。m 参数的值可以是 1 或者 2,对应着 parent 在 merge commit 信息中的顺序。

以上面那张图为例,我们查看 commit g 的内容:

git show g
commit g
Merge: f e
那么,$ git revert -m 1 g 将会保留 master 分支上的修改,撤销 dev 分支上的修改。

撤销成功之后,Git 将会生成一个新的 Commit,提交历史就成了这样:

a -> b -> c -> f -- g -> h -> G (master)
           \      /
            d -> e  (dev)

其中 G 是撤销 g 生成的 commit。通过 $ git show G 之后,我们会发现 G 是一个常规提交,内容就是撤销 merge 时被丢弃的那条线索的所有 commit 的「反操作」的合集。

Recover a Reverted Merging
上面的提交历史在实践中通常对应着这样的情况:

工程师在 master 分支切出了 dev 分支编写新功能,开发完成后合并 dev 分支到 master 分支并上线。上线之后,发现了 dev 分支引入了严重的 bug,而其他人已经在最新的 master 上切出了新的分支并进行开发,所以不能简单地在 master 分支上通过重置(git reset )来回滚代码,只能选择 revert 那个 merge commit。

但是事情还没有结束。工程师必须切回 dev 分支修复那些 bug,于是提交记录变成了这个样子:

a -> b -> c -> f -- g -> h -> G -> i (master)
           \      /
            d -> e -> j -> k (dev)

工程师返回 dev 分支通过 j,k 两个 commit 修复了 bug,其他工程师在 master 上有了新的提交 i。现在到了 dev 分支的内容重新上线的时候了。

直觉上来说,还是和之前一样,把 dev 分支合并到 master 分支就好了。于是:

$ git checkout master
$ git merge dev
得到的提交记录变成了这样:

a -> b -> c -> f -- g -> h -> G -> i -- m (master)
           \      /                    /
            d -> e -> j -> k ---------    (dev)

m 是新的 merge commit。需要注意的是,这不能得到我们期望的结果。因为 d 和 e 两个提交曾经被丢弃过,如此合并到 master 的代码,并不会重新包含 d 和 e 两个提交的内容,相当于只有 dev 上的新 commit 被合并了进来,而 dev 分支之前的内容,依然是被 revert 掉了。

所以,如果想恢复整个 dev 所做的修改,应该:

$ git checkout master
$ git revert G
$ git merge dev
于是,提交历史变成了这样:

a -> b -> c -> f -- g -> h -> G -> i -> G' -- m (master)
           \      /                          /
            d -> e -> j -> k ---------------    (dev)

其中 G‘ 是这次 revert 操作生成的 commit,把之前撤销合并时丢弃的代码恢复了回来,然后再 merge dev 分支,把解 bug 写的新代码合并到 master 分支。

现在,工程师可以放心地上线没有 bug 的新功能了。

原文地址:https://www.cnblogs.com/antball/p/11956043.html

时间: 2024-11-02 23:51:15

git 还原、恢复、回退的相关文章

Git(时光机-版本回退)

现在,你已经学会了修改文件,然后把修改提交到Git版本库,现在,再练习一次,修改readme.txt文件如下: Git is a distributed version control system. Git is free software distributed under the GPL. 然后尝试提交: 像这样,你不断对文件进行修改,然后不断提交修改到版本库里,就好比玩RPG游戏时,每通过一关就会自动把游戏状态存盘,如果某一关没过去,你还可以选择读取前一关的状态.有些时候,在打Boss之

Git教程-版本回退

现在,你已经学会了修改文件,然后把修改提交到Git版本库,现在,再练习一次,修改readme.txt文件如下: Git is a distributed version control system. Git is free software distributed under the GPL. 然后尝试提交: $ git add readme.txt $ git commit -m "append GPL" [master 3628164] append GPL 1 file cha

Git 版本恢复命令reset

reset命令有3中方式: git reset -mixed: 此为默认方式,不带任何参数的git reset, 使用这种方式,项目会回退到某个版本,只保留源码,回退commit和index的信息. git reset -soft: 回退到某个版本,只回退了commit的信息,不会恢复到index file 一级,如果还要提交,直接commit即可 git reset -hard: 彻底回退到某个版本,本地的源码也会变成上一个版本的内容 reset的示例 1 git reset HEAD^ //

Git命令之回退篇 git revert git reset

Git command之回退篇 欲练回退 必先了解:HEAD.index.WorkingCopy HEAD: 当前所在的分支版本顶端的别名,也就是最新的一次commit. git commit 之后与HEAD一致 index: staging area,git add 之后放入该区域 WorkingCopy: 当前修改等操作所在区域,没有 git add 和 git commit 操作 git reset HEAD --file (单个文件) 可与git checkout --file配合 回退

GIt回版本回退

这里我们使用命令行的方式对已经提交的版本进行强行回退操作~~~ 一.将git的安装目录bin放到path路径中, 如下图所示: 二.进入cmd界面,依次输入下面内容即可(git 远程仓库 回退到指定版本) git checkout branches         #检出当前分支 git branch branches_bak   #备份相关分支git reset --hard 版本号         #将本地代码强行回退到指定的版本号git push -f origin branches  

Git操作-版本回退

接着上一节的例子 我们在README.txt文件中再添加一段内容(add modify1): 1 add a file called README 2 add modify1 然后提交到版本库 查看日志 使用$ git log 显示文件的每次提交修改的记录,git log命令显示从最近到最远的提交日志 如果嫌输出信息太多,看得眼花缭乱的,可以试试加上–pretty=oneline参数: 注意:24ee419cb72e7a7baa5814787dd2a63dfe031a34是commit id(版

git 错误操作恢复

前天辛苦用了一天时间,写完关键代码后.用 git 提交,由于修改的东东较多,用一个文件保存了修改的注释,用于 git commit -F commit.txt .由于是在 windows 平台,所以这个文件是用的 gbk 编码.所以提交后,用 git log 查看日志时,出现乱码.此时就想用 git rebase -i HEAD~1 来修改注释.在选择命令时,用了 x ,进行命令行后,我直接 git commit -F commit.txt..导致刚才的提交丢失.所以得恢复刚才的提交. git

[Git] 还原Git上commit,但是没有push代码

直接在Idea上操作2步解决: 1. 找到: 2. 在To Commit里面填写:HEAD^,表示将commit的信息还原为上一次的,需要多次直接reset多次即可: 使用命令行:原理一样 以下内容转载: http://zhyq0826.iteye.com/blog/1671638 如果不小心commit了一个不需要commit的文件,可以对其进行撤销. 先使用git log 查看 commit日志 commit 422bc088a7d6c5429f1d0760d008d86c505f4abe

git的版本回退探索

简介 今天改完代码匆忙提交,上线发现有问题,那怎么办?废话,赶紧回滚,那怎么回滚,开始用git reset [--soft | --mixed | --hard 命令,但这命令真的能达到我预期的效果吗? 每个参数后面的意思又是什么?让人一头雾水,然后用了 reset  --hard命令,并没有达到预期的效果.现在总结下 1.git相关术语 HEAD 这是当前分支版本顶端的别名,也就是在当前分支你最近的一个提交 Index index也被称为staging area,是指一整套即将被下一个提交的文