您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
git checkout 命令详解
 
作者 :hutaoer06051  来源:博客 发布于 2016-8-25
  15722  次浏览      16
 

在日常的Git操作中,git checkout——检出,是我们的常用命令。最为常用的两种情形是创建分支和切换分支。

(一)基础——千里之行,始于切糕(checkout)

先熟悉下常用操作,创建分支和切换分支,也可以称为检出分支。

首先我们新建一个仓库gitTest,然后新建文件a,为什么要用a命名呢,这里是故意为之,后面为大家揭晓分支。或许下面的介绍会有些枯燥乏味,因为您已经对这些命令烂熟于胸,而且运用得相当熟练,那么您可以直接跳过这一步

在master分支上,做一次提交c1,然后现在新建一个分支a,并切换到a分支。

这个操作主要会用到两个命令:

创建新分支:git branch branchName

切换到新分支:git checkout branchName

然后,上面两个命令也可以合成为一个命令:

git checkout -b branchName

(二)真相——HEAD是checkout的灵魂

其实,我们在切换分支,和新建分支的时候,有没有想过,这些操作操作背后的工作原理是怎样的呢?最大的功臣就是.git目录下的HEAD引用,她宛如一个芭蕾舞者,从一个分支飘逸的跳到另一个分支,虽无声无息,却精准无比。

在我们身处master分支的时候,您一定很好奇,当前的HEAD的内容是什么?不妨来看看吧。

我们看到c1的提交hash值和HEAD对应分支master的当前hash值是一样的。也就是说,HEAD指向的是当前分支名master,而master又对应了当前的最新的一次提交ID.

好,那么我们再做一次提交,看看master对应的hash值有无变化。

从上图,我们可以不难看出,HEAD对应的ref没有变化,还是master,但是master对应的commit ID却变成了c2对应的commit ID,即更新为最后一次提交的ID咯。

现在,提交一次的原理,我们已然了解,那么切换分支的时候呢??

现在我们身处master分支,然后我们切换到a分支,看看会发生什么样的情况吧。

从上图分析,在master分支上的时候,HEAD指向的是master,对应的是c2的commit ID。而切换到a分支的时候,HEAD也相应的指向了a,同时a对应的是a分支上的最新commit ID。因此,我们可以得出结论,在切换分支的时候,HEAD也会相应的指向对应的分支引用。

但是,使用checkout命令的时候,并不是每次都会改变HEAD指针的指向哦。在什么情况下HEAD一直坚定不移的拥护者他的女神呢?可谓衣带渐宽终不悔,长使英雄泪满襟啊!让我们接着往下看。

(三)进阶——HEAD动不动,看你怎么用

checkout命令用法如下:

1. git checkout [-q] [<commit>] [--] <paths> ...

2. git checkout [<branch>]

3. git checkout [-m] [ [-b | -- orphan ] <new_branch>] [start_point]

用法2比用法1的区别在于,用法1包含了路径。为了避免路径和引用(或提交ID)同名而发生冲突,可以在<paths>前用两个连续的连字符作为分隔。用法1的<commit>是可选项,如果省略,则相当于从暂存区进行检出。

来看个例子:

情景1,省略掉<commit>

现在我们处于master分支下,然后我们修改了文件a,输入“c3”文本到a中,这时候,暂存区中的内容是没有"c3"的,通过git diff可以比较。现在我们从当前分支暂存区中检出文件a。那么我们可以直接使用git checkout a。

这时候,提示检出失败,git以为我们想检出仓库a。还记得为什么在第一步中,我们曾新建的文件a吗?这里终于派上用场了,由于仓库中还存在分支a,同时当前分支中又存在文件a,于是git傻傻分不清楚了。这时候怎么办?有两个办法,第一,我们在命名分支的时候要注意语义性,分支名要具有一定的意义,不能使用简单的a,b,c来命名,这样很容易导致分支名和文件名重复;第二,参照用法1,使用两个连字符来分隔。在目前的情形中,我们使用第二种方法吧。

这时候,发现工作区的内容被暂存区的内容覆盖,"c3"文本也没有了,当然HEAD指针也没有什么变化,一切又恢复了平静。

再看一个例子:

情景2,不省略<commit>

在不省略<commit>的时候,<commit>既可以是某一个具体的commit hash值,也可以是某个分支名称,tag名称。不论分支也好,tag也好,它们本质上对应的都是一个commit hash值。

在检出a分支下的a文件的时候,最好把两个连字符加上,不然git也会无法区分。整个过程中,HEAD头指针没有发生改动。

总结:第1种用法(包含<paths>的用法)不会改变HEAD头指针,主要使用于指定版本的文件覆盖工作区中对应的文件。如果省略<commit>,则会用暂存区的文件覆盖工作区中的文件,否则用指定提交中的文件覆盖暂存区和工作区中的对应文件。

接下来,我们看看用法2,在第一部分中,我们知道切换分支,会改变HEAD的指向,那么如果我们是检出某个commit会怎样呢?同检出分支一样,会用该commit下的内容覆盖当前分支工作区和暂存区的内容,请看例子。

目前我们处于master分支上,且已经有了两次提交,分别是c1和c2,然后我们修改a,给a文件添加内容"c3",并add到暂存区,随即使用checkout到c1的commit 上。注意,刚开始checkout的时候,git不会允许你直接切换,因为你修改了暂存区的内容, 它会提醒你提交后再切换,这时候,你可以使用-f 强行切换。再查看状态的时候,git提示我们已经不在任何分支上,HEAD指针也是指向具体的c1的commit值,进入了“分离头指针”状态。这个状态下,要回到master上面,只需要git checkout master即可,也可以在这个状态上新建分支。

如果,checkou后面不跟任何参数,则就是对工作区进行检查,请看例子。

我们身处master分支上,并且没有任何改动,这时候git checkout没有任何输出。然后,我们给a文件添加内容“c3”,然后再git checkout一下,git就会提示a文件有修改,是不是很简单?

总结:对于第2种用法,不是检出某个具体文件的的时候,即不指定<paths>的时候,单纯的检出某个commit或分支,是会改变HEAD头指针的。而且只有当HEAD切换到某个分支的时候才可以对提交进行跟踪,否则就会进入“分离头指针”的状态。如果省略用法2后面的<branch>,则默认对工作区进行状态检查。

(四)熟悉的checkout,陌生的用法,妈妈再也不用担心我的checkout啦!

1. git branch <branch> <start point>

以某个commit创建新分支。 在通常情况下,我们都会在当前分支的基础上,创建新分支。比如git branch new_branch 也许你不知道,我们还可以基于当前分支的某一次commit来创建分支。请看!

从上图可见,我们想基于master分支的c1 提交ID创建新分支new_branch,创建成功后,切换到new_branch,查看log,只有c1,耶~~成功啦! 当然,也可以使用git checkout -b <new_branch> <start point>这个常用的命令。

2. git checkout --datch <branch>

切换到分支的游离状态,默认以该分支下的最后一次提交ID,请看下面的例子。 当前分支为a,然后使用git checkout --detach master,那么HEAD就会切换到master的最后一次commit值的状态下!

3. git checkout -B <branch>

这个命令,可以强制创建新的分支,为什么加-B呢?如果当前仓库中,已经存在一个跟你新建分支同名的分支,那么使用普通的git checkout -b <branch>这个命令,是会报错的,且同名分支无法创建。如果使用-B参数,那么就可以强制创建新的分支,并会覆盖掉原来的分支。请看具体操作。 当前分支为master,且仓库中已经存在分支a,我们先用git checkout -b a来创建a分支,必然会失败的,并提示我们仓库中已经有了一个a分支咯,仿佛在说“hi,哥们,你已经有了一个老婆了,一夫一妻制你的不懂?你以为这里是印度啊?”。随后,我们使用git checkout -B a,耶~~,it works!

4. git checkout --orphan <branch>

是的,假如你的某个分支上,积累了无数次的提交,你也懒得去打理,打印出的log也让你无力吐槽,那么这个命令将是你的神器,它会基于当前所在分支新建一个赤裸裸的分支,没有任何的提交历史,但是当前分支的内容一一俱全。新建的分支,严格意义上说,还不是一个分支,因为HEAD指向的引用中没有commit值,只有在进行一次提交后,它才算得上真正的分支。还等什么呢?赶紧试试!

好了,现在我们终于找到组织了!

5. git checkout --merge <branch>

这个命令适用于在切换分支的时候,将当前分支修改的内容一起打包带走,同步到切换的分支下。

有两个需要注意的问题。

第一,如果当前分支和切换分支间的内容不同的话,容易造成冲突。

第二,切换到新分支后,当前分支修改过的内容就丢失了。

所以这个命令,慎用!

6. git checkout -p <branch>

这个命令可以用来打补丁。这个命令主要用来比较两个分支间的差异内容,并提供交互式的界面来选择进一步的操作。这个命令不仅可以比较两个分支间的差异,还可以比较单个文件的差异哦!

结束语:至此,关于git checkout命令暂告一段落,对于checkout命令,你也有所熟悉了吧。当然,git checkout还有一些其它用法,本文并没有讲到,你可以在git bash或终端中使用git checkout --help去进一步了解!

   
15722 次浏览       16
相关文章

每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
相关文档

配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
相关课程

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]

软件配置管理的问题、目的
软件配置管理规范
CQWeb 7.1性能测试与调优指南
为什么需要使用ClearCase
ClearCase与RTC的集成
利用ClearQuest 进行测试管理
更多...   

产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员

配置管理实践(从组织级到项目级)
通号院 配置管理规范与应用
配置管理日构建及持续集成
丹佛斯 ClearCase与配置管理
中国移动 软件配置管理
中国银行 软件配置管理
天津华翼蓝天科技 配置管理与Pvcs