Windows下的Git的下载、安装与使用教程
1. Git的安装1.1 Git的下载1.2 Git的安装
2. Git的常用指令2.1 命名2.2 创建仓库2.3 仓库中添加文件2.4 查看修改文件内容2.5 检查修改次数、时间和修改人2.5 返回历史版本
3. Git的存储与删除3.1 工作区，暂存区与分支3.2 管理修改3.3 撤销修改3.4 删除文件
4. 远程仓库的建立与克隆4.1 远程仓库的建立（Github）4.2 从远程仓库克隆
5. 分支管理5.1 分支的创建与合并5.2 分支冲突5.3 分支管理策略5.4 bug（hotfix）分支5.5 feature分支5.6 推送分支与抓取分支
6. 标签管理6.1 创建标签6.2 标签的操作
7. 本文参考链接
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@example.com"
然后确认邮箱
$ git config user.email
2.2 创建仓库
首先用Git Bash打开D盘
$ cd D:
2.在D盘中创建一个目录（空文件夹）learngit
$ mkdir learngit
3. 打开创建的空目录
$ cd learngit
这里建议创建的目录都用英文字母表示。 输入pwd可以查看当前目录的地址可以发现，目录位于D盘下的learngit文件
$ pwd
把目录变成可以管理的仓库
$ git init
这样仓库就建好了，此时可以发现learngit中多了一个.git它就是用来跟踪和管理仓库中的文件。
2.3 仓库中添加文件
git可以跟踪文本文件的改动，比如txt，代码等，会告知你在第几行添加了什么文字，在第几行改动什么单词，但是git无法跟踪word文件，所以这里建议都使用VS code来作为文本记录工具。下载安装vs code，然后新建一个readme.txt文件并将其保存到learngit文件中去。
在readme文件中键入几句内容： git is a version control system git 是一个可以免费使用的软件 $ sudo apt git 把文件添加到仓库中
$ 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 工作区，暂存区与分支
工作区（Working Directory） 就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区： 在learngit下由一个license和readme文件。这个license文件是随便写的。版本库（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中删除一个字，或者删除一个文件也叫做修改。
我们先添加一个文件到learngit中。 我们直接在文件管理器中把没用的文件删了。这个时候，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上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
githubg地址注册github账户, 网速可能不太好，慢慢来； 注册完毕后 在右上角找到“Create a new repo”按钮，创建一个新的仓库，然后填写仓库的名字learngit，然后创建仓库： 目前，在GitHub上的这个learngit仓库还是空的，我们要把本地的learngit推送到github上，上Git bash上执行命令：
$ git remote add origin git@github.com:name/learngit,git \\其中name是你自己的github的名字，要替换
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
然后执行命令，把本地库的所有内容推送到远程库上：
$ 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
此时我们已经将本地仓库与github连接好了，我们来看看文件同步没有： 可以发现Github中的远程库origin与本地已经一样了，现在只要本地做了提交，就可以通过命令发送给github。命令是：
$ git push origin master
4.2 从远程仓库克隆
4.1是将本地仓库同步到github中，那么github中的文件如何同步到本地呢？
登录github，我们随便搜索一个项目： 复制那个网址：git@github.com:openai/openai-python.git，然后git bash输入指令：
$ git clone git@github.com:openai/openai-python.git
可以看到同步到我们本地了。 当然我们也可以在github上建立一个远程库同步到本地，想要学习的可以参考从远程库克隆。
5. 分支管理
之前我们主要的操作都在工作区和暂存区中，本章重点了解分支的使用和操作。为什么要了解分支呢？有了分支我们就可以多个人分别干活，每个人是一个分支，谁先完成了谁就提交，等到最后合并到一起就完成了整个项目。
5.1 分支的创建与合并
我们在2.5中了解到，每一次的修改之后提交到Git中，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支，HEAD是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。： 当我们创建新的分支，例如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命令查看当前分支：
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变： 比如，我们在readme上添加一句话： Creating a new branch is quick. 然后提交到Git中：
$ git add readme.txt
$ git commit -m "branch test"
此时我们相当于在原来的时间线上完成了新的操作，但是分支在dev上。
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
$ git checkout master \\回到master分支
或者
$ git switche master \\回到master分支
此时我们查看一下readme文件的内容： 发现刚才添加的那句话并没有与原文件合并，这是因为那个信息还在dev分支中，我们将dev的信息合并到当前分支（master）中：
$ git merge dev
再看一下现在readme内容： 可以发现现在分支内容已经合并到当前分支里了。
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
$ git branch -d dev \\删除dev分支
$ git branch \\产看分支
5.2 分支冲突
新建一个分支，修改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
在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"
此时可以看见发生了冲突： 文件内容也有提示，这是因为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：
修复完成后，切换到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
当然如果任务很多的情况下，我们想一个一个恢复，先用git stash list查看，然后恢复指定的stash：
$ git stash list \\查看
$ git stash apply stash@{0} \\ 恢复
如果这个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的新功能，该功能计划用于下一代星际飞船。准备开发：
首先我们随便建立一个c语言文件named vulacn放到learngit中，创建一个新的feature-vulacn的分支：
$ git switch -c feature-vulcan
$ git add vulcan.c
$ git status
$ git commit -m "add feature vulcan"
切回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 \\都可以
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master \\推送master分支
$ git push origin dev \\推送dev分支
如果还有别的分支就把后面的名字改了。但是，并不是一定要把本地分支往远程推送master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。看心情吧。
抓取分支。多人协作时，大家都会往master和dev分支上推送各自的修改。现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆。
$ git clone git@github.com: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
当你的小伙伴已经向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 创建标签
在Git中打标签非常简单，首先，切换到需要打标签的分支上：
$ git branch \\ 查看分支
$ git switch master \\切换到master分支
$ git tag v0.1 \\给master一个v0.1的标签
$ git tag \\查看标签
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？方法是找到历史提交的commit id，然后打上就可以了：
$ git log --pretty=oneline --abbrev-commit \\查看历史commit对应的id
$ git tag v0.9 f81f200 \\根据历史id打标签
$ git tag \\查看标签
注意，标签不是按时间顺序列出，而是按字母排序的。可以用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 标签的操作
删除标签
git tag -d v0.1
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
将标签推送到远程仓库
git push origin v1.0 \\某个标签推送到远程
$ git push origin --tags \\所有标签推送到远程
删除已推送到远程的标签
$ git tag -d v0.9 \\先删除本地的一个标签
$ git push origin :refs/tags/v0.9 \\然后删除一个远程
7. 本文参考链接
1.廖雪峰Git教程 2.Github 3.Git 使用教程：最详细、最傻瓜、最浅显、真正手把手教！ 4.Git的安装步骤、配置
精彩链接
您阅读本篇文章共花了：
发表评论