Git个人总结

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

命令合集

感谢小甲鱼大佬的视频，以下内容均为观看视频后的笔记
视频链接为：https://www.bilibili.com/video/BV1bs411N7ny?share_source=copy_web

以下的章节会讲到下面这些命令

#初次使用Git前得配置
git config --global user.name "用户名" #配置用户名
git config --global user.email "邮箱" #配置邮箱
git config --list #列出关于当前git的所有配置信息

#Git常规操作案例
git init #在目录中创建新的 Git 仓库
git add 文件名 #将文件提交到暂存区
git  add   file1 file2#提交file1 file2到暂存区
git add . #是将当前的文件夹提交到暂存区(不包含隐藏文件)
git add * #是将所有文件提交到暂存区

#Git查看状态案例
git status #查看目前分支的状态
git restore --staged 文件名 #恢复暂存区域成之前的样子，将暂存区将这个文件移除
git restore 文件名 #恢复工作区的文件，恢复成之前没被修改的样子
git log #查看历史记录

#Git回到过去__reset
git reset HEAD~ #加上一个波浪线就是指回退到上一个版本
git reset HEAD~n #回退到第n个版本
git reset  版本号  # 指定回滚到具体版本，这个方式，往前回滚的时候，记得还要在执行git checkout 文件名
git reflog  # 查看曾经所有的操作（如果窗口关了，没有记住哈希值，可以通过它查看以前的操做）
git reset --soft HEAD~ #单纯回退到上一个版本，但是暂存区和工作区还是最没回退前新版本的内容,主要用于撤销上一次的提交commit
git reset --hard HEAD~ #将暂存区还原到工作目录，也就是回退到上个版本刚刚commit后的样子，三棵树均一致的内容

#版本对比
git diff #对比   他会比较暂存区和工作区文件内容的差异
git diff 版本1的id  版本2的id # 比较版本1和版本2的额呢绒
git diff --cached #将仓库中最新提交的版本与暂存区进行对比
git diff --cached 版本id #指定仓库版本与暂存区做对比

#小技巧
git commit -amend #修改最新一次提交，会进入新的界面让我们修改说明，修改后用vim命令退出会自动提交
git commit --amend -m "新的说明" # 不会进入新的界面，直接就修改新一次提交的说明并提交
git rm "文件名" #删除某个文件（记得带文件的后缀名），删除的只是工作区目录和暂存区的文件，也就是取消了Git的跟踪，下一次提交时，不在受到Git的管理
git rm -f "文件名" #强制删除工作区和暂存区的文件
git rm --cached "文件名" #只删除暂存区，保留工作区的文件
git mv "旧文件名" "新文件名" # 重命名文件名，例如：git mv demo1.py work_demo1.py

#创建和切换分支
git branch "分支名" #创建分支
git branch #查看查看本地分支，并显示目前所在的分支
git branch -a #查看全部分支(包含本地和远程)
git log --decorate #是log显示指向这个提交的所有引用，比如说我们的分支
git checkout "分支名" #切换分支
git log --decorate --oneline #一行显示一个版本，只会显示版本的id和说明

#合并和删除分支
#注意：执行合并的时候要先切回到主分支，再执行下面这个命令
git merge "分支名" #合并分支
git checkout -b feature2  #创建了一个分支feature并切换到feature
git branch -d "分支名"# 删除分支

#匿名分支和checkout命令
git checkout HEAD~ #匿名分支的创建
git branch 新的分支名 版本ID号 #将匿名分支创建为新的分支

初次使用Git前得配置

初次使用的时候为了让git知道使用者是谁

• 在命令行模式里面输入以下命令：

  git config --global user.name “用户名”

  git config --global user.email “邮箱”

• 输入后检查看是否配置成功：

  git config --list
  

Git记录的是什么

Git的版本记录

Git则是将每个版本独立保存，例如：

File1有5个版本，它就存了File1的5个拷贝，这种虽然占据了很多的空间，但是在分支操作上有很多的便利

三棵树

三棵树就是他们的工作区域，暂存区域和Git仓库

工作区域：就是平时我们存放项目的地方，我们能看得见摸得着的地方，比如C 盘下的MY_project文件夹

暂存区域：就是用于临时存放文件改动，事实上它是一个文件，保存的就是即将 提交到仓库的一个列表信息，所有有时候也叫index

Git仓库：是最终提交代码，安全存放所有版本数据的位置，里面有我们提交的所 有版本的数据，也就是每次执行git commit 命令的数据,其中HEAD指针指向 的就是最新提交的版本数据

Git的工作流程

• Git的工作流程一般是这样的：工作区域–>暂存区–>Git仓库

  1.在工作目录中添加、修改文件

  2.将需要进行版本管理的文件放入暂存区域

  3.将暂存区域的文件提交到Git仓库

• Git管理的文件有三种状态

  — 已修改（modified）

  — 已暂存（staged）

  — 已提交（committed）

Git常规操作案例

下面将演示文件创建到提交到仓库的一整完整的流程，只需两个步骤

• 第一我们在自己的电脑的一个位置上创建一个文件夹，用于存放项目。执行下面命令，这里我是在自己的电脑E:创建了一个My_project文件夹，执行命令后会出现一个隐藏的文件.git 这个文件我们可以通过电脑的“查看”，将“隐藏的目录”勾选就能看得到

git init #表示这个文件夹已经初始新的 Git 仓库

• 第二我们在文件夹中创建一个README.md文件，执行以下命令，先将文件提交到暂存区，最后提交到仓库，这就是一套完整的创建到提交到仓库的常规流程

  git add README.md #将README.md文件提交到暂存区
  git commit -m "add a readme file" #将文件提交到仓库，-m表示本次操作的说明
  
  #下面的操作是拓展：
  git  add   file1 file2#提交file1 file2到暂存区
  git add . #是将当前的文件夹提交到暂存区(不包含隐藏文件)
  git add * #是将所有文件提交到暂存区
    --例子：将1.jpg提交到暂存区
  	git add 1.jpg
  

Git查看状态案例

我们可以通过下面的命令查看状态，如果显示工作区域是干净的那么就表示这个文件没有被改动过

git status #查看当前分支的状态

MIT协议

MIT协议说白了就是要使用我的代码，你只需要包含我这个协议文件就可以了，也就是说别人可以拿你的代码披上别人的外壳，然后改的面目全非再用于商业都是合法的。

案例

以下，我们将创建一个文件，并对文件进行修改后再查看状态，以此来熟悉Git的查询状态的命令

• 首先 ，我们在文件夹中创建了了LICENSE.txt文件，我们通过查看状态git status会发现，出现了红色的字体，这里我对下方图片说明一下

Untracked files: # 表示"未跟踪文件"，也就是新添加的文件，并没有将文件提交到暂存区，一旦提交到暂存区之后就会被Git跟踪了
    
(use "git add <file>..." to include in what will be committed) # 表示git给了我们一个建议，我们可以执行git add 将文件提交到暂存区

 红色字体LICENSE.txt #就表示这个文件是我们刚刚创建的，未被跟踪

• 其次，我们按照Git给的提示执行git add LICENSE.txt，效果如下图。此时我们发现我们字体颜色变成了绿色，对此说明以下

1.当我们执行git add LICENSE.txt 后再执行git status就会出现下面的现象

2.(use "git restore --staged <file>..." to unstage) #表示Git给我们提示，执行 git restore --staged LICENSE.txt恢复暂存区域。因为我们刚刚将将文件提交到了暂存区，如果我们突然反悔不想让Git跟踪我们的文件就可以使用这个命令，换句话说就是将暂存区中将这个文件移除
git restore --staged 文件名 #恢复暂存区域成之前的样子，将暂存区中将这个文件移除

• 然后，我们将LICENSE.txt文件提交到暂存区git add ，再执行git commit -m “add a license file” 提交到仓库。此时我们想修改了一下LICENSE.txt，修改完后，然后再执行git status查看发现它给出了2行提示，如下图显示，我对此说明以下

   (use "git add <file>..." to update what will be committed)# 这个表示我们可以用 git add LICENSE.txt 将暂存区的LICENSE.txt文件更新到最新
      
  (use "git restore <file>..." to discard changes in working directory)# 这个表示我们可以使用git restore LICENSE.txt 将暂存区的LICENSE.txt 覆盖掉我们文件夹所修改的这个LICENSE.txt文件，也就是恢复工作区的文件，恢复成之前没被修改的样子
  
  modified:   LICENSE.txt# 表示文件被修改了
  

• 最后根据它给的提示直接git add LICENSE.txt 然后git commit LICENSE.txt -m ‘xx’ 就提交成功了

特殊情况

​ 本来我们增加了一个文件LICENSE.txt，执行了git add 提交到暂存区之后，我们查看了状态，发现是提示1行绿色的字体。但是再在执行git commit提交到仓库的时候我们把这个文件给改了，然后通过git status查看的时候就会提示一行绿色一行红色的字

​ 情况说明：

执行第二个git status之后出现的绿色字体，说明了文件放在了暂存区等待被git commit。同时红色字体说明文件还在工作目录等待被 git add.

这里同时存在了两个不同版本的LICENSE文件
绿色的是指有"DaiLiWei"这个内容的LICENSE,处于暂存区
红色的是有"DaiLiWei_1"这个内容的LICENSE，处于工作区，是我们准备commit的时候修改的LICENSE

如果执行git commit LICENSE.txt会将有"DaiLiWei"这个内容的LICENSE提交
如果是将有"DaiLiWei_1"这个内容的LICENSE提交，那么需要先执行git add来覆盖暂存区域的LICENSE文件，也就是红色覆盖掉绿色的LICENSE文件，再执行git commit

此时我使用了红色字体的提示来提交

查看历史记录

git log

Git回到过去__reset

​ 过去无法挽回，未来可以改变——《一人之下》

Git可以使用版本控制，将文件还原到之前的各个版本。本小结主要讲解reset命令

小案例

以下操作，我们会了解到reset命令具体不是如何影响指针以及三棵树的情况

首先，我们通过git log查看历史记录，可以看到Git仓库有三个版本，分别是增加了一个readme文件，一个license文件以及修改了license文件，这几个版本我们都通过commit命令提交到仓库，所以我们可以查看到仓库也会有这三个版本

此时，Git仓库目前的状态应该就是如下图所示的样子。其中HEAD指针指向的就是我们最新提交的版本94d061，图中的v1 v2指的是文件的版本

我们知道了目前仓库所指向的版本，那么三棵树的状态是什么样子的呢？正如下图所示，因为我们最后的操作是修改了LICENSE，通过git add 提交到暂存区，再git commit提交到了仓库，所以三个区域的文件都是一致的

然后，我们通过下面的命令来回退版本

git reset HEAD~#加上一个波浪线就是指回退到上一个版本 也就是1c4c69
#这个命令，一个波浪线就是一个版本，10个波浪线就是10个版本
#例如：
git reset HEAD~~~~~ #回退了5个版本
git reset HEAD~10#可以简写成这样，波浪线加数字就是回退多少个版本，这里就表示回退了10个版本

效果如下图，此时它回退到了1c4c69这个版本的暂存区

那么回退之后，此时三棵树的状态是什么样子的呢？如下图

​ 我们先看仓库的状态和三棵树的状态，此时，指针指向了第二个版本。Git时刻跟踪我们的版本变比，当指针指向1c4c69版本的时候，也就是回退1c4c69版本的时候，那么它的暂存区和仓库内容都是一样的。因为当初1c4c69这个版本的操作就是增加了一个LICENSE，且成功commit。

​ 那他为什么提示我们下面这句话呢？因为工作区是v2版本，Git检测到v2是比v1新的，所以提示我们工作区还没有被staged（暂存）

(use "git add <file>..." to update what will be committed)

(use "git restore <file>..." to discard changes in working directory)

	modified:   LICENSE.txt
#因为这些文字和在工作区准备提交到暂存区的时候的提示很像所以会产生一种错觉以为在工作区

reset命令的选项

git reset  版本号  # 指定回滚到具体版本，可回退也能前进，但是往前回滚的时候加上最好是git reset --hard 版本号，不然前进后还要执行git checkout 文件名
git reflog  # 查看曾经所有的操作（如果窗口关了，没有记住哈希值，可以通过它查看以前的操做）
git reset --soft HEAD~ #单纯回退到上一个版本，但是暂存区和工作区还是最没回退前新版本的内容,主要用于撤销上一次的提交commit
git reset --hard HEAD~ #将暂存区还原到工作目录，也就是回退到上个版本刚刚commit后的样子，三棵树均一致的内容

git reset --hard HEAD~ 效果展示：

我们现在所在的版本是在1c4c69，执行后直接回到cf9289版本，且直接回退到cf9289版本刚刚commit之后的样子

版本对比

在开始之前呢，我们需要做一些准备工作：

• 首先我们在E盘下重新下重新创建了一个My_project2的文件 mkdir My_project2

• 在这个文件中我们初始化一个Git仓库 git init

• 在将写有内容的py文件和README.md文件复制进去

• 最后我们将他们提交到Git仓库中 git add README.md demo1.py git commit -m “number python file”

操作完上面之后我们在对py文件和README.md文件进行修改，效果展示如下：

此时我们执行下面的命令，会出现以下的效果

git diff#对比   他会比较暂存区和工作区文件内容的差异

对此图片中所展示的内容我进行说明以下：

diff --git a/README.md b/README.md #表示对比存放在暂存区的README  与 工作区的README 他们被Git分别放到ab文件中做对比

index 4d178c6..504ecd0 100644
#4d178c6表示a文件的id
#504ecd0表示b文件的id
#100644表示文件的类型与权限

--- a/README.md #表示旧文件，放在暂存区的文件
+++ b/README.md #表示新文件，工作区的文件

@@ -1 +1,3 @@ #-负号表示旧文件 +正号表示新文件
#-1表示旧文件从第一行开始显示
#+1，3表示新文件从第一行显示，一共3行(看上面图的对比，发现多了一行空格)

\ No newline at end of file #这是Git的提醒，隔开上一次显示

绿色字体是新文件所增加的内容
白色的是两个文件共有的内容
红色的就是旧文件的内容
: #后面有一个冒号是因为内容太多无法显示完，在等待我们敲击命令
命令如下：
J 表示向下移动  K向上移动
F 表示一页一页的往下移动  B表示一页一页的往上移动
D 向下移动半页	U向上移动半夜
输入数字+g会跳到指定行数
小写g跳到第一行  大写G跳到最后一行

此时我们通过git status会看到两个红色的文件，表示工作区目前有两个更新的文件，问我们是否提交到暂存区或者是否使用git restore将暂存区的文件覆盖掉目前工作区的文件

比较两个历史快照

git diff 版本1的id  版本2的id

比较当前工作目录和Git仓库中的版本

git diff 版本的id #这样他会自动将工作区的内容与改版本做对比

比较暂存区和Git仓库的版本

git diff --cached #他会直接将仓库中最新提交的版本与暂存区进行对比
git diff --cached 版本id #指定仓库版本与暂存区做对比

小技巧

​ 本小结将会讲解如何修改最后一个提交，如何删除文件，如何恢复以及重命名的小技巧

修改最后一次提交

• 在实际开发中，我们可能会遇到以下两种情景：

  情景一：版本刚提交（commit）到仓库，突然想起漏掉两个文件还没有添加（add）到暂存区

  情景二：版本刚提交（commit）到仓库，突然想起来版本说明写得不够全面，也就是git commit -m "xxxx"中的"xxx"写得不够全面，无法彰显本次修改的意义

解决方案：那么针对以上的两种情况，我们可以给出了解决方案

​ 执行带 --amend 选项的commit 提交命令，Git就会"更正"最近一次提交

git commit -amend #修改最新一次提交，会进入新的界面让我们修改说明

情景一的解决方式

此时，我们通过git log命令看到仓库一共有两个版本，分别是5298277和82ec402。再通过git status查看到暂存区有最新的README.md文件。

​ 这个时候，我们想将暂存区的README.md文件提交到仓库里去，但是又不想让仓库多出一个版本，那么我们就可以执行git commit -amend操作。此时，我们进入到新的界面（这个界面用到的都是vim的命令），这个界面是用于修改提交说明的，如果不需要修改，直接退出就好。

当退出后，它会提示我们

[master 4177266] delete note and update README.md 主分支的说明

Date: Mon Aug 23 01:52:05 2021 +0800 修改的时间

2 files changed, 5 insertions(+), 10 deletions(-)，以及修改的文件

​ 我们再通过git status查看，暂存区已经没有任何新的文件需要commit了，也就证明我们已经将暂存区的文件提交到仓库了

​ 我们再git log查看一下会发现，仓库还是两个版本，只是最新的版本id变了，不再是5298277了。这里我把原来的说明给改了。之前的是"delete note" 现在是"delete note and update README.md"

情景二的解决方式

此时，我们想修改最新一次提交的说明那么只需要执行下面的命令即可

git commit --amend #会进入新的界面，用于修改最新一次提交的说明
git commit --amend -m "新的说明" # 不会进入新的界面，直接就修改新一次提交的说明

删除文件

我们都知道，只要文件被Git跟踪后，就很难脱离Git的掌控

比如我们手动删除了README.md文件

我们再通过git status查看，此时Git就会意识到有个文件被偷偷的删除掉了。那么Git也会提醒我们可以使用git restore “文件名” 恢复到工作区

git restore "文件名" #使工作区的文件恢复到之前的一个状态

#注意：
git restore --staged "文件名" #将暂存区的文件从暂存区中移除出来

我们尝试一下使用Git提示给我们的命令，此时我们发现文件又回来了

那么既然Git很难删除文件，我们如何删除一个文件呢？

我们假设一个场景，我们不小心将一个叫“密码”的文件放进去工作区，并且还git add *提交所有文件到了暂存区了，最后还git commit -m “add all”，此时怎么办呢？

不用担心，我们可以直接执行以下命令

git rm "文件名" #删除某个文件（记得带文件的后缀名），删除的只是工作区目录和暂存区的文件，也就是取消了Git的跟踪，下一次提交时，不在受到Git的管理

#这个命令删除后，无法使用git restore "文件名" 恢复文件

​ 但是，我们执行后查看状态发现还是会看到这个文件哦，万一文件是不雅的文件被别人通过git status看到就不好啦

此时我们只需要修改下HEAD的指针就好啦，上面我们已经讲过可以使用下面这个命令

git reset --soft HEAD~ #取消上一次commit提交

如下图的效果，仓库的版本只剩下2个，指针指向的是4177266的版本，通过git status也看不到"密码.txt"文件了

删除的文件的特殊情况

此时我们看到工作区是干净的，然后我们自己创建了一个test.py文件，然后我们执行git add test.py 提交的暂存区。

提交之后我们再对test.py文件进行修改，此时我们再通过git status会发现，出现了两个不同颜色的test.py,绿色是代表在暂存区的，红色是代表工作区最新的版本的test.py文件

此时我们再执行git rm test.py Git就会提示我们我们是要删除哪个文件，并且提示我们可以使用下面的命令强制删除

git rm -f "文件名" #强制删除工作区和暂存区的文件
git rm --cached "文件名" #只删除暂存区，保留工作区的文件

重命名文件

有时候在工作中，经常对文件进行增删改出，但是经过这一系列的CURD之后呢，文件名就部再适合了，那么就要修改文件名，那怎么办呢？比如下面的图中的说明

当使用git status查看，会发现Git提示我们，我们是不是删除了demo_1的文件，然后又整了一个work_demo_1的文件进来了

此时我们把它给改回去，他又变成clean了，原来Git也不是非常的智能化，那么我们该怎么重新命名文件呢？

我们只需要执行下面的命令，然后执行git status就会看到Git提示我们修改了文件的名字，最后我们要记得执行git commit 命令才会生效哦

git mv "旧文件名" "新文件名" # 重命名文件名，例如：git mv demo1.py work_demo1.py

创建和切换分支

​ 在项目中，我们一般都是创建一个新的分支用于开发新的功能，当开发完后进行调试，最后再合并到master主分支上。说白了其实分支就是把主分支master的全部文件都拷贝了一次，当我们修改分支的时候就不会影响到主分支了

创建分支

语法如下

git branch "分支名" #创建分支
git branch #查看查看本地分支，并显示目前所在的分支
git branch -a #查看全部分支(包含本地和远程)
git log --decorate #是log显示指向这个提交的所有引用，比如说我们的分支

这里我们看到创建了一个feature的分支，通过git log --decorate看到仓库版本ID后面多了个小括号，HEAD指针指向master主分支

切换分支

语法如下

git checkout "分支名" #切换分支
git log --decorate --oneline #一行显示一个版本，只会显示版本的id和说明

​ 当我们执行上面的命令后，会发现HEAD指向了feature。因为我们使用了oneline,所以只会显示4177266这个版本

此时我们对文件中README.md文件进行修改

​ 我们再通过git add 提交到暂存区，最后执行git commit提交到仓库。当我们使用git log查看的时候就会发现，它其实修改的其实是分支feature下的README.md文件，并不是主分支的README.md。

​ 我们能看到最新版本460937指针HEAD依旧是指向feature的，证明我们还在feature分支下的

​ 下面我们就来证明一下，如下图，我们再切换到主分支master下，打开README.md就会发现，那行Powered by me不见了。其实不是不见了，是这行字压根就部存在，它是存在与feature这个分支上的README.md上的

​ 我们通过切换不同的分支查询log会发现，不同的分支上指针所指的位置不一样，并且版本显示也不一样。它只会显示改分支下仓库下的版本

合并和删除分支

当我们分支调试且讨论之后，都觉得Ok后，那么就要合并到主分支了。如下图，我们执行命令看到目前分支是再master分支下的。那么再合并的时候总会遇到一些奇奇怪怪的问题

合并冲突

命令如下

#注意：执行合并的时候要先切回到主分支，再执行下面这个命令
git merge "分支名" #合并分支

​ 当我们执行这个命令后会发现，Git会告诉我们失败了，有一个冲突。那是什么冲突呢，通过git status 查看，原来主分支和feature分支有同名文件README.md，但是内容不同，Git不知道我们舍弃哪一个，保留哪一个，所以需要我们人为的自行修改

​ 那么它提示我们 “Unmerged paths:” 还没有合并的路径，那是哪里呢？就是这个README.md文件，所以我们就要对这个文件进行修改，看看要保留哪些内容

当我们要打开这个README.md文件的时候，我们会发现Git会在文件上做上标记，那么我们只需要将我们要保留的部分保留，该删除的删除，然后提交commit就可以了

此时我们执行git add 提交到暂存区，再commit就OK了

合并不冲突

命令如下

git checkout -b feature2  #创建了一个分支feature并切换到feature

​ 当我们的文件不冲突的情况下，执行git merge “分支名” 那么就直接合并到主分支上了。

此时我们模拟一下下面的场景：

首先，git checkout -b feature2 先切换到feature2

然后，我们创建了一个文件叫feature.txt，提交到暂存区

最后，切换到主分支git checkout master 进行合并，执行git merge feature2。此时没有任何的报错，那是因为主分支合并之前并没有feature.txt文件，所以feature2分支和主分支不存在任何的冲突

图中箭头指向的 “Fast-forward” 是代表 “快进” 的意思，这是为什么呢？是因为feature2的父节点是master，指针HEAD原来是指向feature2，现在只是将master移动上来了，指针指向了master

删除分支

命令

git branch -d "分支名"# 删除分支
#例如我们删除之前分支
git branch -d feature
git branch -d feature2

#查看全部分支(包含本地和远程)
git branch -a

此时我们删除了两个分支后，我们查看分支，就会发现目前只剩下一个master主分支了

匿名分支和checkout命令

本小结我们将重点讲解什么是匿名分支和讲讲checkout和reset命令的区别

匿名分支

​ 如下图所示，我们看到Git仓库中有3个版本，并且目前HEAD指针指向了最新一次提交的d9236d6版本上面

通过上的 “创建和切换分支” 和 “Git回到过去” 这两个小结我们知道：

当执行git checkout “分支名” 就会切换到对应的分支上

当执行git reset HEAD~ 就会回退到上一个版本

上图中显示，目前只有一个主分支并没有其他的分支了，那么如果我们执行下面的命令会发生什么呢？

git checkout HEAD~ #匿名分支的创建

那下面的图片意思为：

当我们使用git checkout 但是没有指定分支名，所以Git会自动创建一个匿名分支并切换到该匿名的分支

在这个匿名分支所作的所有操作，只要切换到了其他分支，那么匿名分支的操作都会被丢弃掉，所以提示我们可以用匿名分支来做试验，不会有什么影响

此时文件夹的情况是什么样的呢？此时我们看到文件夹3.txt不见了，因为指针指向的是2.txt这个版本。

我们在该文件夹下再创建一个4.txt并且commit，此时我们再通过git log --decorate --oneline --all --graph 图形的方式查看，目前HEAD指向4.txt，并且匿名分支和主分支master向不同方向发展

但当我们切换回主分支就发现4.txt不见了，而3.txt又回来了并且Git给出了警告。Git说，如果我们要保留这个匿名的分支为一个新的分支，那么可以使用下面这个命令。

git branch 新的分支名 版本ID号 #将匿名分支创建为新的分支

切换之后，匿名分支也讲究荡然无存了，所以我们要做一些实验的时候，可能会对程序又 风险，那么我们就可以使用匿名分支

checkout命令

checkout命令有两种功能：

• 从历史版本或者 暂存区 中拷贝文件到 工作区 git checkout --文件名
• 切换分支 git checkout 分支名