美文网首页
Git分支管理-版本回退-撤销文件修改

Git分支管理-版本回退-撤销文件修改

作者: 南南南NaN | 来源:发表于2020-02-19 16:11 被阅读0次

1、Git分支管理策略

1.1、主分支Master

首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。

image

Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。

1.2、开发分支Develop

主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

image

这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。

Git创建Develop分支的命令

git checkout -b develop master

将Develop分支发布到Master分支的命令

 # 切换到Master分支
git checkout master

# 对Develop分支进行合并
git merge --no-ff develop

这里稍微解释一下,上一条命令的--no-ff参数是什么意思。默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将Master分支指向Develop分支。

image

使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。关于合并的更多解释,请参考Benjamin Sandofsky的《Understanding the Git Workflow》

image

1.3、临时性分支

前面讲到版本库的两条主要分支:Master和Develop。前者用于正式发布,后者用于日常开发。其实,常设分支只需要这两条就够了,不需要其他了。

但是,除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:

  • 功能(feature)分支
  • 预发布(release)分支
  • 修补bug(fixbug)分支

这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。

1.4、功能分支

接下来,一个个来看这三种"临时性分支"。

第一种是功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

image

功能分支的名字,可以采用feature-*的形式命名。

#创建一个功能分支
git checkout -b feature-x develop

#开发完成后,将功能分支合并到develop分支
git checkout develop
git merge --no-ff feature-x

#删除feature分支
git branch -d feature-x

1.5、预发布分支

第二种是预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-*的形式。

创建一个预发布分支
git checkout -b release-1.2 develop

确认没有问题后,合并到master分支
git checkout master
git merge --no-ff release-1.2
 
对合并生成的新节点,做一个标签
git tag -a 1.2

再合并到develop分支:
git checkout develop
git merge --no-ff release-1.2

最后,删除预发布分支:
git branch -d release-1.2

1.6、修补bug分支

最后一种是修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。

image

创建一个修补bug分支:

 git checkout -b fixbug-0.1 master

修补结束后,合并到master分支:

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

再合并到develop分支:

 git checkout develop
git merge --no-ff fixbug-0.1

最后,删除"修补bug分支":

 git branch -d fixbug-0.1

2、 版本回退-撤销文件修改

{针对文件修改恢复}

2.1、工作区修改一个文件后,又想回到修改前

(1). 当然可以直接手动再在工作区中将文件修改回去

(2). 修改后,通过命令git status查看

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)#
#       modified:   readme.txt
#no changes added to commit (use "git add" and/or "git commit -a")

这时Git会告诉你,git checkout -- file可以丢弃工作区的修改:

$ git checkout -- readme.txt

笔记:

1. git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到git checkout命令。

2. 命令git checkout -- readme.txt意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:

一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。总之,就是让这个文件回到最近一次git commit或git add时的状态。

2.2、如果在工作区中修改了文件还git add到暂存区(但是在commit之前)

用git status查看一下,修改只是添加到了暂存区,还没有提交:

$ git status
# On branch master# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#       modified:   readme.txt

Git同样告诉我们,用命令git reset HEAD file可以把暂存区的修改撤销掉(unstage),重新放回工作区:

$ git reset HEAD readme.txt 
Unstaged changes after reset:M       
readme.txt

git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。

再用git status查看一下,现在暂存区是干净的,工作区有修改。

然后丢弃工作区的修改

$ git checkout -- readme.txt 
$ git status
# On branch masternothing to commit (working directory clean)

2.3、 不但修改了文件还从暂存区提交commit到了版本库 - 版本回退

版本回退可以回退到上一个版本。不过,这是有条件的,就是你还没有把自己的本地版本库推送到远程。Git是分布式版本控制系统。

在工作中对某个文件(如readme.txt)进行多次修改交commit。

可以通过版本控制系统命令告诉我们提交的历史记录,在Git中,我们用git log命令查看:

$ git log 
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 15:11:49 2013 +0800     
append GPL 

commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 14:53:12 2013 +0800     
add distributed 

commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 19 17:51:55 2013 +0800    
wrote a readme file

笔记:

  1. git log命令显示从最近到最远的提交日志,我们可以看到3次提交,最近的一次是append GPL,上一次是add distributed,最早的一次是wrote a readme file。

2. 如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数:

$ git log --pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPLea
34578d5496d7dd233c827ed32a8cd576c5ee85 add distributedcb
926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
  1. 你看到的一大串类似3628164...882e1e0的是commit id(版本号),和SVN不一样,Git的commit id不是1,2,3……递增的数字,而是一个SHA1计算出来的一个非常大的数字,用十六进制表示,而且你看到的commit id和我的肯定不一样,以你自己的为准。为什么commit id需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。

  2. 每提交一个新版本,实际上Git就会把它们自动串成一条时间线。如果使用可视化工具(如GitX、github的客户端、pycharm)查看Git历史,就可以更清楚地看到提交历史的时间线。0

2.4、现在我们想要把readme.txt回退到上一个版本

如“add distributed”的那个版本,怎么做呢?首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD表示当前版本,也就是最新的提交3628164...882e1e0(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD,上上一个版本就是HEAD,当然往上100个版本写100个比较容易数不过来,所以写成HEAD~100。

现在,我们要把当前版本“append GPL”回退到上一个版本“add distributed”,就可以使用git reset命令:

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

这时readme.txt的内容就成了版本add distributed

我们用git log再看看现在版本库的状态:

$ git log 

commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Tue Aug 20 14:53:12 2013 +0800     
add distributed 

commit cb926e7ea50ad11b8f9e909c05226233bf755030
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Mon Aug 19 17:51:55 2013 +0800     
wrote a readme file

最新的那个版本append GPL已经看不到了!

2.5、恢复文件后,要是我们又想回到修改后的文件呢?(命令行窗口还没有被关掉)

{这个是git reset --hard后,又反悔了,想回到修改后的状态}

只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个append GPL的commit id是3628164...,于是就可以指定回到未来的某个版本:

$ git reset --hard 3628164
HEAD is now at 3628164 append GPL

版本号没必要写全,前几位就可以了,Git会自动去找。

Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是把HEAD从指向append GPL:

git-head

改为指向add distributed:

git-head-move

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号,你就把当前版本定位在哪。

2.6、 恢复文件后,要是我们又想回到修改后的文件呢?(命令行窗口早就关掉了)

{这个是git reset --hard后,又反悔了,想回到修改后的状态}

想恢复到新版本怎么办?找不到新版本的commit id怎么办?当你用$ git reset --hard HEAD^回退到add distributed版本时,再想恢复到append GPL,就必须找到append GPL的commit id。

Git提供了一个命令git reflog用来记录你的每一次命令:[Git高级教程:git log与git reflog]

$ git reflogea34578 HEAD@{0}: 
reset: moving to HEAD^3628164 HEAD@{1}: 
commit: append GPLea34578 HEAD@{2}: 
commit: add distributedcb926e7 HEAD@{3}:
commit (initial): wrote a readme file

第二行显示append GPL的commit id是3628164,现在,你又可以乘坐时光机回到未来了。

转载原文链接:https://blog.csdn.net/WEB_CSDN_SHARE/article/details/79243308

相关文章

  • Git 命令

    将目录转化为Git仓库 添加文件到Git仓库 查看状态 版本回退 撤销修改 远程仓库 分支 多人协作

  • Git 常用技巧

    撤销修改 撤销本地修改 或者 切换分支 切换到前一分支 切换到某个分支 创建新分支 版本回退 回退 个版本...

  • Git分支管理-版本回退-撤销文件修改

    1、Git分支管理策略 1.1、主分支Master 首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的...

  • Git 的使用

    1、 安装git2、创建版本仓库3、添加文件到 git仓库4、修改文件、版本回退、撤销修改、删除文件5、工作区和暂...

  • git  提交代码常用命令

    代码回退: git reset --hard HEAD^切换分支:git checkout name撤销修改:gi...

  • git常用命令总结

    1、清除 当前目录下所有本地文件的修改 2、撤销 git add . 已经添加到缓存的文件 3、版本回退 git ...

  • git

    初始化操作 版本回退 checkout 撤销文件内容 删除文件 分支

  • Git常用操作

    常用命令 版本回退 撤销修改 删除文件

  • 常用Git命令

    总结一些常用Git命令 创建版本库 配置 修改和提交 查看提交历史 撤销 版本回退 分支与标签 合并与衍合 远程操...

  • git使用手册

    邮箱名字 初始化仓库 提交更改、比对 版本回退 撤销修改 删除文件 分支合并 注意 远程仓库-》删除 远程仓库-》...

网友评论

      本文标题:Git分支管理-版本回退-撤销文件修改

      本文链接:https://www.haomeiwen.com/subject/phpafhtx.html