Git的下载、安装与使用(Windows)

1. Git的安装

1.1 Git的下载

(1) 官方地址：https://git-scm.com/download/win
(2) 镜像地址：https://registry.npmmirror.com/binary.html?path=git-for-windows/
因为官方地址下载可能会缓慢所以这里建议使用镜像地址下载。镜像地址离包含的是Git的所有历史版本，因此要选择一个最新的版本，这里可以对比一下官方地址的版本号，然后去镜像地址找到对应的文件下载下来就可以了。比如我下载的是2.39.2 64bit的版本：

那么镜像地址中就找到对应的版本即可：

1.2 Git的安装

1.修改安装位置

2. next，继续next，继续next，一直next，知道最后一步点击Install。当然这里只是简单的操作，如果想详细了解每一步的作用都是什么建议去这个网址中详细了解Git 详细安装教程（详解 Git 安装过程的每一个步骤）
3. 安装完成后，电脑应用程序中会出现：

4. 打开Git Bash

5. 到这个步骤就安装完成啦！！！

2. Git的常用指令

2.1 命名

在Git Bash命令框对自己的Git仓库进行命名：

$ git config --global user.name "Your Name" //Your Name替换成自己的名字

回车，然后：

$ git config user.name //确认名字是否输入成功

回车，然后给出自己的邮箱：

$ git config --global user.email "[email protected]"

然后确认邮箱

$ git config user.email

2.2 创建仓库

1. 首先用Git Bash打开D盘

$ cd D:

2.在D盘中创建一个目录（空文件夹）learngit

$ mkdir learngit

3. 打开创建的空目录

$ cd learngit

这里建议创建的目录都用英文字母表示。

输入pwd可以查看当前目录的地址可以发现，目录位于D盘下的learngit文件

$ pwd

4. 把目录变成可以管理的仓库

$ git init

这样仓库就建好了，此时可以发现learngit中多了一个.git它就是用来跟踪和管理仓库中的文件。

2.3 仓库中添加文件

git可以跟踪文本文件的改动，比如txt，代码等，会告知你在第几行添加了什么文字，在第几行改动什么单词，但是git无法跟踪word文件，所以这里建议都使用VS code来作为文本记录工具。下载安装vs code，然后新建一个readme.txt文件并将其保存到learngit文件中去。

1. 在readme文件中键入几句内容：
   git is a version control system
   git 是一个可以免费使用的软件
   $ sudo apt git
   
   
2. 把文件添加到仓库中

$ git add readme.txt

3. 把文件提交到仓库中

$ git commit -m "wrote a readme file"

git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；3 insertions：插入了两行内容（readme.txt有两行内容）。为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt
$ git add file2.txt 
$ git add file3.txt
$ git commit -m "add 3 files."

2.4 查看修改文件内容

接下来我们在vs code 中对readme文件进行内容的修改：

git is a version control system
git 是一个可以免费使用的软，并且使用的人很多
$ cd D:
然后运行：

$ git status

上面的命令输出告诉我们，readme.txt被修改过了（modified: readme.txt
），但还没有准备提交的修改（no changes added to commit）。虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用git diff这个命令看看：

$ git diff readme.txt \\查看具体被修改的内容

git diff顾名思义就是查看difference，可以从上面的命令输出看到，我们原本的内容（红色字体），和修改后的内容（绿色字体）的对比。知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了。提交修改和提交新文件是一样的两步：

$ git add readme.txt
$ git status
$ git commit -m "add word and code"
$ git status

git status表示查看当前仓库的状态，git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了git commit。提交后，我们再用git status命令看看仓库的当前状态。

现在我们已经学会了修改文件并将修改后的文件提交到Git库中。

2.5 检查修改次数、时间和修改人

上述只是修改了一次，当我们对一个文件进行多次修改，并存到Git库中去。例如：当我们在修改一次readme的内容：

git is a version control system，that distributed
git 是一个可以免费使用的软，并且使用的人很多,用起来也方便
$ cd D:

$ git diff readme.txt %观察修改后的内容
$ git status 
$ git add readme.txt %添加
$ git status
$ git commit -m "word and code"
$ git status

在实际工作中，我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容，不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：

$ git log

在这里我们可以看见什么时间修改的，修改人都有谁。都做了什么修改（git commit -m "word and code"后的作用）。可以看到最近一次修改的是word and code，上一次修改时add word and code。也可以简化信息的显示内容：

$ git log --pretty=oneline

这样可以让显示的信息变少：

2.5 返回历史版本

当我们感觉当前修改的版本不如历史版本的时候，我们想让readme文件回到上一步应该如何处理？
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交cbd208f2ab81415a2315365c87a303982a4a4fae，上一个版本就是HEAD^, 对应的edaafe8159efb2dd00628dcc80c1a69c51ea38ca，网上100个版本写成HEAD~100。

$ git reset --hard HEAD^ 

可以发现他已经回到edaafe8，即上一个版本。
查看一下readme中的内容：

$ cat readme.txt

那么现在问题来了，我感觉这个HEAD^的版本不如HEWD的版本好，我想回到刚才那个版本怎么办。如果命令窗口没关闭的话找HEAD对应的版本号。版本号是唯一的。例子中HEAD对应的版本号是cbd208f2ab81415a2315365c87a303982a4a4fae，取前几位就好了，Git回自己找。

$ git reset --hard cbd208

在查看一下readme的内容：

那么命令窗口被关闭咋办？
Git提供了一个命令git reflog可以记录你的每一次命令（版本号）：

$ git reflog

还可以看见每一次的（commit）操作信息，然后再使用get reset指令就可以回来了。

3. Git的存储与删除

3.1 工作区，暂存区与分支

1. 工作区（Working Directory）
   就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：
   在learngit下由一个license和readme文件。这个license文件是随便写的。
2. 版本库（Repository）
   2.2中我们将learngit这个目录添加到仓库时发现还有一个. git文件，他是工作区中隐藏的目录，称为版本库。Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
   
   这个图的大概意思是：
   第一步是用git add把目录文件（learngit）添加到添加到Git (版本库) 中，实际上就是把文件修改添加到暂存区；
   第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

章节2中我们已经对readme文件进行了多次修改，我们来看看此时git的状态：

此时提示还有一个没跟踪（Untracked）的文件license，因为reademe没有修改所以没有提示。我们先把license添加到Git中。然后看一下状态：

git add license
git status

状态提示添加了一个新文件。那么此时的暂存区变成这样：

然后把暂存区的修改提交到分支，在看一下状态：

git commit -m "understand how stage works"
git status

此时所有的文件都提交到分支中了，现在版本库变成了这样，暂存区就没有任何内容了：

3.2 管理修改

通过第二章我们知道对learngit中的文件进行删除或添加文字，甚至添加了新文件，这都叫修改。Git管理的是修改，而不是管理文件。 这样理解可能比较生涩，看下面这个例子：
我们在vs code中修改readme文件的内容：

然后回到git bash中，添加readme文件，并观察状态：

$ git add readme.txt
$ git status

然后在回到vs code中修改readme文件的内容：

然后提交到GIt中，看一下状态：

$ git commit -m "add chinses"git
$ git status

这里提示，有一个改变并没有存到committed中。我们看看修改后的内容：

git diff HEAD -- readme.txt 

而我们此时工作区的内容是：
git is a version control system，that distributed
git 是一个可以免费使用的软，并且使用的人很多,用起来也方便
$ cd D:
Git has a mutable index called stage.
Git tracks changes.
Git可以跟踪修改
可以发现后面两个绿色的句子并没有添加到commit中。原因是Git只会管理修改，第一次修改 然后 git add之后会存到暂存区，准备提交到Git中，第二次修改并没有存到暂存区，所以最终往Git中提交时，只提交了第一次的修改。
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：
第一次修改 -> git add -> 第二次修改 -> git add -> git commit

3.3 撤销修改

假如你发现你刚才在readme文件中添加一句新的话：
我最讨厌使用git
十分不符合项目需求，此时git status，可以发现文件已经改变了：

这里有一句话use "git restore file " to discard changes in working directory，中文意思时使用git restore可以把工作区的修改抹掉。我们执行一下这个语句：

git restore readme.txt
cat readme.txt

可以发现我们添加的我最讨厌使用git已经被移除了。
那么我们来看第二种情况，你修改完文件之后，还执行了git add操作，此时文件已经进入了暂存区，但是还没引用到commit中，我们可以用之前学的命令：

$ git reset HEAD readme.txt

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

3.4 删除文件

在Git中删除一个字，或者删除一个文件也叫做修改。

1. 我们先添加一个文件到learngit中。
   
   

2. 我们直接在文件管理器中把没用的文件删了。这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
   
   3.现在有两个选择，一是确实要从版本库中删除test文件，那就用命令git rm删掉，并且git commit：

git rm test.txt
git commit -m "remove test.txt"

这样不仅工作区删除了，版本库中也删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git restore .txt

那么共工作区的文件就恢复了。

当然如果这个工作区的文件从来没有添加到过版本库中，那么是无法恢复的。

4. 远程仓库的建立与克隆

4.1 远程仓库的建立（Github）

之前我们已经在本地建立了自己的仓库，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。

1. githubg地址注册github账户, 网速可能不太好，慢慢来；

2. 注册完毕后 在右上角找到“Create a new repo”按钮，创建一个新的仓库，然后填写仓库的名字learngit，然后创建仓库：
   
   

3. 目前，在GitHub上的这个learngit仓库还是空的，我们要把本地的learngit推送到github上，上Git bash上执行命令：

$ git remote add origin [email protected]:name/learngit,git \\其中name是你自己的github的名字，要替换

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

4. 然后执行命令，把本地库的所有内容推送到远程库上：

$ git push -u origin master

实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样.
这个过程可能会出现两个问题：
第一个问题：

解决方法：这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：Warning: Permanently added ‘github.com’ (RSA) to the list of known hosts.这个警告只会出现一次，后面的操作就不会有任何警告了。
第二个问题： Please make sure you have the correct access rights and the repository exists
解决方法：参考博客
第三个问题：error: remote origin already exists.
解决方法：

$ git remote -v
$ git remote rm origin

这个指令是删除本地与github之间的联系，并不会删除github的文件，如果想删除掉GitHub中的文件需要去github网站找到name/learngit→settings→一直向下滑有个delat

5. 此时我们已经将本地仓库与github连接好了，我们来看看文件同步没有：
   
   
   可以发现Github中的远程库origin与本地已经一样了，现在只要本地做了提交，就可以通过命令发送给github。命令是：

$ git push origin master

4.2 从远程仓库克隆

4.1是将本地仓库同步到github中，那么github中的文件如何同步到本地呢？

1. 登录github，我们随便搜索一个项目：
   
   
   
   复制那个网址：[email protected]:openai/openai-python.git，然后git bash输入指令：

$ git clone [email protected]:openai/openai-python.git

可以看到同步到我们本地了。

当然我们也可以在github上建立一个远程库同步到本地，想要学习的可以参考从远程库克隆。

5. 分支管理

之前我们主要的操作都在工作区和暂存区中，本章重点了解分支的使用和操作。为什么要了解分支呢？有了分支我们就可以多个人分别干活，每个人是一个分支，谁先完成了谁就提交，等到最后合并到一起就完成了整个项目。

5.1 分支的创建与合并

我们在2.5中了解到，每一次的修改之后提交到Git中，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支，HEAD是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

1. 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。：
   
2. 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
   
   语句如下：

$ git checkout -b dev

或者

$ git branch dev
$ git checkout dev

或者

$ git switch -c dev

他们是一样的

可以看到此时分支已经从master转到dev上了。可以用git branch命令查看当前分支：

3. 从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
   
   比如，我们在readme上添加一句话：
   Creating a new branch is quick.
   然后提交到Git中：

$ git add readme.txt
$ git commit -m "branch test"

此时我们相当于在原来的时间线上完成了新的操作，但是分支在dev上。

4. 假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
   

$ git checkout master \\回到master分支

或者

$ git switche master \\回到master分支

此时我们查看一下readme文件的内容：

发现刚才添加的那句话并没有与原文件合并，这是因为那个信息还在dev分支中，我们将dev的信息合并到当前分支（master）中：

$ git merge dev

再看一下现在readme内容：

可以发现现在分支内容已经合并到当前分支里了。

5. 合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
   

$ git branch -d dev \\删除dev分支
$ git branch \\产看分支

5.2 分支冲突

1. 新建一个分支，修改readme的内容，然后执行add 和 commit，最后在转换到master节点：

$ git switch -c feature1
\\redame.txt 中最后一行的内容改成：Creating a new branch is quick AND simple.
$ git add readme.txt
$ git commit -m "and simple"
$ git switch master

2. 在master分支上给readme文件添加一行内容（Creating a new branch is quick & simple.）然后add添加，在commit提交，并合并中：

\\给readme文件添加Creating a new branch is quick & simple
$ git add readme.txt
$ git commit -m "thired"

3. 此时可以看见发生了冲突：
   
   文件内容也有提示，这是因为mater和feature1，都有自己的新的提交内容，当合并时，Git只能试图把各自的修改合并起来，合并可能会引发冲突。
   
   我们手动修改readme文件，然后add，commit提交：
   
   
   此时分支情况变成这样：
   
   最后删除分支 git branch -d feature1：
   

5.3 分支管理策略

上面那种分支合并的方式我们称之为Fsast forward，这种模式下删除分支后，会丢失分支信息，无法看不到曾经合并的信息。在实际开发过程中，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，如下图所示，就是一个简单的分支管理过程。

因此使用–no-ff的方式进行分支合并：

$ git switch -c dev \\创建一个新的分支dev
\\ 修改readme文件，自行修改
$ git add readme.txt \\add添加
$ git commit -m "merge" \\commit引用
$ git switch master \\转到master
$ git merge --no-ff -m "merge with no-ff" dev   \\使用--no-ff的方式合并def分支到master

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。从上面我们知道，master分支是稳定的，不能轻易动，我们改动都是再dev分支上，它是不稳定，那么其它分支的作用是什么？

5.4 bug（hotfix）分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时bug分支来修复。修复后，合并bug分支，然后将临时bug分支删除。因此当我们接收到一个代号为001的bug任务时，我们首先应该创建一个bug分支，名字为“issue-001”，然后修复master。但是如果当前dev的工作正在提交到master，那么应该如何处理呢？

$ git stash

Git提供了一个stash功能，可以把当前工作现场“储藏”起来（即dev正在干的事情），等以后恢复现场（bug修复后）后继续工作（继续回到dev）。git stash之后要用git state查看一下当前工作区是不是干净的，如果干净的话就可以创建bug分支来修复bug。

1.假设现在readme文件中有一句话git是一个不好用的软件，那么我们修复bug就是把它改为git是一个好用的软件。首先我们要确定bug分支建立再哪个分支上。假如我们要建立在master分支上，那么就：

$ git checkout -b issue-001

2. 然后修复bug，我们将readme中的文件修改，再进行add， commit：

3. 修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git switch master
$ git merge --no-ff -m "merged bug fix 101" issue-101
$ git branch -d issue-001

4.此时完成了bug修复，我们需要再恢复dev的工作。Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

$ git stash apply
$ git stash drop

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

git stash pop

5. 当然如果任务很多的情况下，我们想一个一个恢复，先用git stash list查看，然后恢复指定的stash：

$ git stash list \\查看
$ git stash apply stash@{0} \\ 恢复

6. 如果这个bug是从dev分支传到master中的，那么我们是不是要用同样的方式修复dev？
   同样的bug，要在dev上修复，我们只需要把issue-001 29a7604这个提交所做的修改“复制”到dev分支。注意：我们只想复制issue-001 29a7604这个提交所做的修改，并不是把整个master分支merge过来。为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的内容提交到当前分支（dev）：

$ git branch
$ git cherry-pick 29a7604

此时Git自动给dev分支做了一次提交。我们就不需要在提交了。

5.5 feature分支

在开发过程中总会有无穷无尽的新要求要添加，添加一个新功能时，你肯定不希望因为一些实验性质的代码，把dev分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。准备开发：

1. 首先我们随便建立一个c语言文件named vulacn放到learngit中，创建一个新的feature-vulacn的分支：

$ git switch -c feature-vulcan
$ git add vulcan.c
$ git status
$ git commit -m "add feature vulcan"

2. 切回dev，准备合并feature，然后删除feature

$ git switch dev
$ git branch -d feature-vulcan

但是发现没删掉，提示，需要使用大写的-D参数。现在我们强行删除：

git branch -D feature-vulcan

5.6 推送分支与抓取分支

当一个项目自己无法完成的时候，我们需要多人协作，那么就需要我们从远程仓库克隆，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

1.首先查看远程库的信息：

$ git remote \\或者$ git remote -v  \\都可以

2. 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master \\推送master分支
$ git push origin dev \\推送dev分支

如果还有别的分支就把后面的名字改了。但是，并不是一定要把本地分支往远程推送master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。看心情吧。

3. 抓取分支。多人协作时，大家都会往master和dev分支上推送各自的修改。现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆。

$ git clone [email protected]:name7/learngit.git

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，用这个命令创建本地dev分支：

$ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

$ git add env.txt
$ git commit -m "add env"
$ git push origin dev

4. 当你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送那么可能或产生冲突，解决办法也很简单，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送。
   如果git pull失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接，再给git pull，再提交，再push：

$ git branch --set-upstream-to=origin/dev dev
$ git pull
$ git commit -m "fix env conflict"
$ git push origin dev

6. 标签管理

什么是标签？

比如我们想要发布一个软件的版本，通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e…”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

6.1 创建标签

1. 在Git中打标签非常简单，首先，切换到需要打标签的分支上：

$ git branch \\ 查看分支
$ git switch master \\切换到master分支
$ git tag v0.1  \\给master一个v0.1的标签
$ git tag \\查看标签

2. 默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？方法是找到历史提交的commit id，然后打上就可以了：

$ git log --pretty=oneline --abbrev-commit \\查看历史commit对应的id
$ git tag v0.9  f81f200  \\根据历史id打标签
$ git tag \\查看标签

3. 注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show 查看标签信息，比如：

$ git show v0.9

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

$ git tag -a v0.8 -m "version 0.1 released" 4a09528
$ git show v0.8

6.2 标签的操作

1. 删除标签

git tag -d v0.1

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

2. 将标签推送到远程仓库

git push origin v1.0 \\某个标签推送到远程
$ git push origin --tags  \\所有标签推送到远程

3. 删除已推送到远程的标签

$ git tag -d v0.9 \\先删除本地的一个标签
$ git push origin :refs/tags/v0.9 \\然后删除一个远程

7. 本文参考链接

1.廖雪峰Git教程
2.Github
3.Git 使用教程：最详细、最傻瓜、最浅显、真正手把手教！
4.Git的安装步骤、配置