git教程

Git 教程

前言

认识版本控制

• 版本控制的英文是Version control；
• 是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程
• 版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步；

简单来说，版本控制在软件开发中，可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作

版本控制的功能

◼ 对于我们日常开发，我们常常面临如下一些问题，通过版本控制可以很好的解决：

◼ 不同版本的存储管理：

• 一个项目会不断进行版本的迭代，来修复之前的一些问题、增加新的功能、需求，甚至包括项目的重构；
• 如果我们通过手动来维护一系列的项目备份，简直是一场噩梦；

◼ 重大版本的备份维护：

• 对于很多重大的版本，我们会进行备份管理；

◼ 恢复之前的项目版本：

• 当我们开发过程中发生一些严重的问题时，想要恢复之前的操作或者回到之前某个版本；

◼ 记录项目的点点滴滴：

• 如果我们每一个功能的修改、bug的修复、新的需求更改都需要记录下来，版本控制可以很好的解决；

◼ 多人开发的代码合并：

• 项目中通常都是多人开发，将多人代码进行合并，并且在出现冲突时更好的进行处理；

版本控制的历史

◼ 版本控制的史前时代（没有版本控制）：

• 人们通常通过文件备份的方式来进行管理，再通过diff命令来对比两个文件的差异；

◼ CVS（Concurrent Versions System）

• 第一个被大规模使用的版本控制工具，诞生于1985年；
• 由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的，也算是SVN的前身（SVN的出现就是为了取代CVS的）。

◼ SVN（Subversion）

• 因其命令行工具名为svn因此通常被简称为SVN；
• SVN由CollabNet公司于2000年资助并发起开发，目的是取代CVS，对CVS进行了很多的优化；
• SVN和CVS一样，也属于集中式版本控制工具；
• SVN在早期公司开发中使用率非常高，但是目前已经被Git取代；

◼ Git（Linus的作品）

• 早期的时候，Linux社区使用的是BitKeeper来进行版本控制；
• 但是因为一些原因，BitKeeper想要收回对Linux社区的免费授权；
• 于是Linus用了大概一周的时间，开发了Git用来取代BitKeeper；
• Linus完成了Git的核心设计，在之后Linus功成身退，将Git交由另外一个Git的主要贡献者Junio C Hamano来维护；

集中式版本控制

◼ CVS和SVN都是是属于集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）

• 它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本；
• 协同开发人员通过客户端连接到这台服务器，取出最新的文件或者提交更新；

◼ 这种做法带来了许多好处，特别是相较于老式的本地管理来说，每个人都可以在一定程度上看到项目中的其他人正在做些什么。

◼ 但是集中式版本控制也有一个核心的问题：中央服务器不能出现故障：

• 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作；
• 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据；

分布式版本控制

◼ Git是属于分布式版本控制系统（Distributed Version Control System，简称 DVCS）

• 客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录；
• 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复；
• 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份；

◼ 目前在公司开发中我们都是使用Git来管理项目的，所以接下来我们会重点学习Git的各种用法；

鲁迅曾经说过：“任何事情都有两面性，既有好的一面也会有坏的一面”，就像git，它既简单又复杂，为什么简单呢？因为常用的命令也就那么几个，多使用几次就能轻松掌握。复杂的是它的原理及更深入的实现机制。当然对于大部分人来说，时间是宝贵的，把有限的时间用在对我们有利的事情上才是正确的选择，所以本教程也是讲述git的工作日常使用，并不是对git底层的深入探索，看完本篇教程只能算是会使用git，但想成为git专家，那还远远不够，也不需要。

一、Git是什么？

git是一个分布式的版本控制工具

什么是分布式？

分布式顾名思义就是指服务分散部署在不同的机器上，与之对应的就是集中式。分布式的架构使得git代码安全性更高，因为每个人电脑中都有完整的版本库，都有最新的代码。

什么是版本控制？

版本控制（Revision control）是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

Git的诞生

linux之父linus早期因为没有版本控制工具，对于世界各地Linux贡献者提交的代码，只能手工方式进行合并代码，在Linux发展了十年之后，代码量已经大到Linus无法用手工方式合并代码了，于是使用了BitMover公司为Linux社区免费提供的版本控制系统BitKeeper，后来因为Linux社区的samba软件开发者Andrew试图破解BitKeeper，被BitMover公司及时发现，于是收回了Linux社区的免费使用权。Linus花了两周时间用C写了分布式版本控制系统——Git，于是Git就这样诞生了，如果不是BitMover公司的收回，可能现在我们就没有免费好用的git了。

二、为什么使用Git？

Git优势

• 大部分操作在本地完成，不需要联网
• 完整性保证
• 尽可能添加数据而不是删除和修改数据
• 分支操作非常快捷流畅
• 与Linux命令全面兼容

为什么使用版本控制工具

在没有使用版本控制工具以前，在写的代码中想要删除一部分或者一个文件，但又担心以后想恢复找不回来怎么办？于是只好复制这个文件做一个备份记录下来，但久了就会产生很多文件，过了一周，想要再次找回被删除的文件，此时已经记不清是在哪里删除的了，郁闷。并且和团队协同开发时，共享代码麻烦，需要将他人的代码拷贝到自己电脑上然后对比修改的部分再进行添加，实在是要命！

于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？

于是版本控制工具应运而生，他的主要功能

• 协同修改
  • 多人并行不悖的修改服务器端的同一个文件。
• 数据备份
  • 不仅保存目录和文件的当前状态，还能够保存每一个提交过的历史状态。
• 版本管理
  • 在保存每一个版本的文件信息的时候要做到不保存重复数据，以节约存储空 间，提高运行效率。这方面 SVN 采用的是增量式管理的方式，而 Git 采取了文件系统快照的方式
• 权限控制
  • 对团队中参与开发的人员进行权限控制
  • 对团队外开发者贡献的代码进行审核——Git 独有
• 历史记录
  • 查看修改人、修改时间、修改内容、日志信息。
  • 将本地文件恢复到某一个历史状态。
• 分支管理
  • 允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。

三、如何使用Git？

在 window 安装Git

官网下载安装程序：https://git-scm.com/downloads，按照默认安装即可

安装完成后，配置名称邮箱，在任意文件夹中右键选择Git bash Here进入命令行

输入以下命令配置代码提交时显示的名字和邮箱

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

注意：这里设置的名称和邮箱与登录远程仓库的账号、密码没有任何关系

Git 配置分类

既然已经在系统上安装了 Git，你会需要做几件事来定制你的 Git 环境：

• 每台计算机上只需要配置一次，程序升级时会保留配置信息；
• 你可以在任何时候再次通过运行命令来修改它们；

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量：

• /etc/gitconfig 文件：包含系统上每一个用户及他们仓库的通用配置
  ✓ 如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量；
  ✓ 由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它。（开发中通常不修改）
• ~/.gitconfig 或 C/用户/admin/.gitconfig 文件：只针对当前用户
  ✓ 你可以传递 --global 选项让 Git 读写此文件，这会对你系统上 所有 的仓库生效；
• 当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对该仓库
  ✓ 你可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它；

Git 别名

Git 并不会在你输入部分命令时自动推断出你想要的命令：

• 如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。

git config --global alias.st status
git st == git status

Git工作原理

从右往左看

• workspace：工作区 ，就是你在电脑里能看到的目录，比如一个项目文件夹
• index：暂存区 ，用于保存需要commit的文件，暂存区的意义是它将你准备提交的内容分批整体处理
• Repository：本地仓库 ，工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库即本地仓库
• Remote：远程仓库

git 暂存区的意义：https://blog.csdn.net/qq_36383623/article/details/103090793

文件状态流转

上面介绍了文件在不同区域的流转，咱们还需要了解一下文件本身的状态，以及不同命令对文件状态的影响。理解这几个状态直接的流转，有助于看清 Git 本质。

• 没有被add过的文件叫untracked

• add之后文件处于staged状态等待commit

• commit之后文件处于unmodified状态

• 当unmodified的文件被修改则会变为modified状态

• modified之后的文件add之后将继续变为staged状态

• unmodifed的文件还有一种可能是已经不再需要了，那么可以remove它不再追踪变为untracked状态

Git操作流程图

Git常用命令

初始化仓库

# 方式一：克隆远程仓库到本地
git clone https://gitee.com
# 方式二：初始化本地仓库
git init

本地仓库初始化后会在目录中生成一个.git的文件夹，里面就是git本地库文件

注意：.git 目录中存放的是本地库相关的子目录和文件，不要删除，也不要胡乱修改

设置签名

作用：区分不同开发人员的身份

• 项目仓库级别：仅在当前本地库范围内有效

  git config user.name "your name"
  git config user.email "name@qq.com"
  

  配置信息保存位置：./.git/config 文件

• 系统用户级别：登录当前操作系统的用户范围

  git config --global user.name "your name"
  git config --global user.email "name@qq.com"
  

  配置信息保存位置：~/.gitconfig 文件

• 配置文件优先级

  就近原则：项目级别>系统级别，二者都没有时不允许

本地文件操作

git status
git status -s
# 查看git工作区状态
git diff
# 显示当前工作区的文件和stage区文件的差异
git add [file name]
# 或
git stage [file name]
# 添加当前工作区所有文件到暂存区
git commit -m "commit message" [file name]
# 提交暂存区文件到本地仓库
git commit -a -m "commit message"
# 添加并提交

查看历史记录

git log
# 多屏显示控制方式
# 空格向下翻页
# b 向上翻页
# q 退出

git log --pretty=oneline --graph
git log --pretty=oneline
git log --oneline
# 单行显示
git reflog
# 显示每次版本切换的记录，用于回退版本后查看之前的版本号
# HEAD@{移动到当前版本需要多少步}

前进后退

版本前进后退的本质是HEAD指针的移动

• 基于索引值操作【推荐】

  git reset --hard [局部索引值]
  git reset --hard 5b7f847
  

• 使用^符号：只能后退

  git reset --hard HEAD^
  # 一个^表示后退一步，n 个表示后退 n 步
  

• 使用~符号：只能后退

  git reset --hard HEAD~n
  # 表示后退 n 步
  

reset 命令的三个参数对比

• –soft

  仅在本地库移动 HEAD 指针

• –mixed

  在本地库移动 HEAD 指针，重置暂存区

• –hard

  在本地库移动 HEAD 指针，重置暂存区，重置工作区

暂存区、工作区回退

git restore --staged <file>
# 回退已经提交到暂存区的文件到本地工作区
git restore <file>
# 重置本地工作区未提交到暂存区的改变

自git的新版本2.23后，git checkout命令将被替换，新版本引入的是两个新命令 git switch 和 git restore，用以替代现在的 git checkout

git switch 切换分支

git restore 重置文件

删除文件找回

前提：删除前，文件存在时的状态在本地库有记录

git reset --hard [指针位置]
# 删除操作已经提交到本地库：指针位置指向历史记录
# 删除操作尚未提交到本地库：指针位置使用 HEAD

比较文件差异

git diff [文件名]
# 将工作区文件和暂存区比较
git diff [本地库中历史版本] [文件名]
# 将工作区中的文件和本地库历史记录比较

分支管理

什么是分支？

分支是用来将特性开发绝缘开来的。在版本控制过程中，使用多条线来同时推进多个任务，每一条线就是一条分支，例如在初始化后，git就会为我们默认创建一条master分支

每次提交，Git都把提交的版本串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

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

通常，合并分支时，如果可能，Git会用Fast forward模式，即上图中这种方式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

分支的好处

• 同时并行推进多个功能开发，提高开发效率
• 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可

分支操作

创建分支

git branch [分支名]

创建并切换分支

git checkout -b [分支名]
git switch -c [分支名]

查看分支

git branch -v
git branch # 查看当前所有的分支
git branch –v # 同时查看最后一次提交
git branch --merged # 查看所有合并到当前分支的分支
git branch --no-merged # 查看所有没有合并到当前分支的分支

删除分支

git branch –d hotfix # 删除当前分支
git branch –D hotfix # 强制删除某一个分支

切换分支

git checkout [分支名]
git switch [分支名]

Git社区发布了Git的新版本2.23。在该版本中，有一个特性非常引人瞩目，就是新版本的Git引入了两个新命令 git switch 和 git restore，用以替代现在的 git checkout。换言之，git checkout 将逐渐退出历史舞台。

引用自：https://www.cnblogs.com/tinywan/p/12344267.html

合并分支

git merge [分支名]
# 强制禁用`Fast forward`模式
git merge --no-ff -m "commit message" [分支名]

解决冲突

在合并代码时，由于同时修改了同一个文件的同一行内容，导致合并冲突，这时候需要我们手动修改冲突代码进行提交

如上图，合并dev分支冲突，冲突文件为a.txt

查看冲突的文件可以知道，当前分支master的a.txt文件的内容为master，而dev分支的a.txt文件内容为ccc，所以造成合并冲突，这时候只需要根据自身需要修改a.txt，然后commit冲突就解决了

分支在实际开发中的应用

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Git工作流

◼ 由于Git上分支的使用的便捷性，产生了很多Git的工作流：
 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支；
 你可以定期地把某些主题分支合并入其他分支中；
◼ 比如以下的工作流：
 master作为主分支；
 develop作为开发分支，并且有稳定版本时，合并到master分支中；
 topic作为某一个主题或者功能或者特性的分支进行开发，开发完成后合并到develop分支中；

远程分支的管理

◼ 操作一：推送分支到远程
 当你想要公开分享一个分支时，需要将其推送到有写入权限的远程仓库上；
 运行 git push <remote> <branch>；

git push origin <branch>

◼ 操作二：跟踪远程分支
 当克隆一个仓库时，它通常会自动地创建一个跟踪 origin/master 的 master 分支；
 如果你愿意的话可以设置其他的跟踪分支，可以通过运行 git checkout --track <remote>/<branch>
 如果你尝试检出的分支 (a) 不存在且 (b) 刚好只有一个名字与之匹配的远程分支，那么 Git 就会为你创建一个跟踪分支；
◼ 操作三：删除远程分支
 如果某一个远程分支不再使用，我们想要删除掉，可以运行带有 --delete 选项的 git push 命令来删除一个远程分支。
远程分支的管理
git checkout --track <remote>/<branch>
git checkout <branch>
git push origin --delete <branch>

Git rebase

◼ 在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。

◼ 什么是rebase呢？
 在上面的图例中，你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次；
 在 Git 中，这种操作就叫做 变基（rebase）；
 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样；
 rebase这个单词如何理解呢？
✓ 我们可以将其理解成改变当前分支的base；
✓ 比如在分支experiment上执行rebase master，那么可以改变experiment的base为master

git checkout experiment
git rebase master

rebase的原理

◼ rebase是如何工作的呢？
 它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master） 的最近共同祖先 C2；
 然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件；
 然后将当前分支指向目标基底 C3；
 最后以此将之前另存为临时文件的修改依序应用；
◼ 我们可以再次执行master上的合并操作：
$ git checkout master
$ git merge experiment

rebase和merge的选择

◼ 开发中对于rebase和merge应该如何选择呢？
◼ 事实上，rebase和merge是对Git历史的不同处理方法：
 merge用于记录git的所有历史，那么分支的历史错综复杂，也全部记录下来；
 rebase用于简化历史记录，将两个分支的历史简化，整个历史更加简洁；
◼ 了解了rebase的底层原理，就可以根据自己的特定场景选择merge或者rebase。
◼ 注意：rebase有一条黄金法则：永远不要在主分支上使用rebase
 如果在main上面使用rebase，会造成大量的提交历史在main分支中不同；
 而多人开发时，其他人依然在原来的main中，对于提交历史来说会有很大的变化；

远程仓库

远程仓库即本地仓库在远程主机上的备份仓库，可以供其他主机下载克隆。

在局域网环境

• Gitlab服务器

外网环境下

• Github
• 码云

远程仓库的验证

◼ 常见的远程仓库有哪些呢？目前比较流行使用的是三种：

• GitHub：https://github.com/
• Gitee：https://gitee.com/
• 自己搭建Gitlab：http://152.236.185.210:7888/

对于私有的仓库我们想要进行操作，远程仓库会对我们的身份进行验证：

• 如果没有验证，任何人都可以随意操作仓库是一件非常危险的事情；

目前Git服务器验证手段主要有两种：

• 方式一：基于HTTP的凭证存储（Credential Storage）；
• 方式二：基于SSH的密钥；

下面我们来具体讨论一下这两种方式的验证规则和过程；

远程仓库的验证 – 凭证

◼ 因为本身HTTP协议是无状态的连接，所以每一个连接都需要用户名和密码：
 如果每次都这样操作，那么会非常麻烦；
 幸运的是，Git 拥有一个凭证系统来处理这个事情；
◼ 下面有一些 Git Crediential 的选项：
 选项一：默认所有都不缓存。 每一次连接都会询问你的用户名和密码；
 选项二：“cache” 模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中，并且在15分钟后从内存中清除；
 选项三：“store” 模式会将凭证用明文的形式存放在磁盘中，并且永不过期；
 选项四：如果你使用的是 Mac，Git 还有一种 “osxkeychain” 模式，它会将凭证缓存到你系统用户的钥匙串中（加密的）；
 选项五：如果你使用的是 Windows，你可以安装一个叫做 “Git Credential Manager for Windows” 的辅助工具；
✓ 可以在 https://github.com/Microsoft/Git-Credential-Manager-for-Windows 下载。

远程仓库的验证 – SSH密钥

◼ Secure Shell（安全外壳协议，简称SSH）是一种加密的网络传输协议，可在不安全的网络中为网络服务提供安全的传输环境。
◼ SSH以非对称加密实现身份验证。
 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接，随后使用密码认证进行登录；
 另一种方法是人工生成一对公钥和私钥，通过生成的密钥进行认证，这样就可以在不输入密码的情况下登录；
 公钥需要放在待访问的电脑之中，而对应的私钥需要由用户自行保管；
◼ 如果我们以SSH的方式访问Git仓库，那么就需要生产对应的公钥和私钥：

ssh-keygen -t ed25519 -C "your email"
ssh-keygen -t rsa -b 2048 -C "your email"

管理远程服务器

◼ 查看远程地址：比如我们之前从GitHub上clone下来的代码，它就是有自己的远程仓库的：
git remote
git remote –v
-v是—verbose的缩写(冗长的)

◼ 添加远程地址：我们也可以继续添加远程服务器（让本地的仓库和远程服务器仓库建立连接）：
git remote add <shortname> <url>
git remote add gitlab http://152.236.185.210:7888/coderwhy/gitremotedemo.git

◼ 重命名远程地址：git remote rename gitlab glab

◼ 移除远程地址：git remote remove gitlab

本地分支的上游分支
如果我们想要直接执行git fetch是有一个前提的：必须给当前分支设置一个跟踪分支：

git branch --set-upstream-to=origin/master
git pull

◼ 从远程仓库clone代码：将存储库克隆到新创建的目录中；

git clone http://152.136.185.210:7888/coderwhy/gitremotedemo.git 

◼ 将代码push到远程仓库：将本地仓库的代码推送到远程仓库中；
 默认情况下是将当前分支（比如master）push到origin远程仓库的；

git push
git push origin master

◼ 从远程仓库fetch代码：从远程仓库获取最新的代码
 默认情况下是从origin中获取代码；

git fetch
git fetch origin

 获取到代码后默认并没有合并到本地仓库，我们需要通过merge来合并；

git merge

◼ 从远程仓库pull代码：上面的两次操作有点繁琐，我们可以通过一个命令来操作远程仓库的交互

git pull
git fetch + git merge(rebase)

常见的开源协议

Github远程仓库的创建

一、创建前的准备

完成本地git客户端和GitHub服务器的密钥认证，在用户主目录（~）下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。

1. 生成本地密钥对

   ssh-keygen -t rsa -C "youremail@example.com"
   

   邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

2. Github端添加本地客户端ssh公钥

二、 开始创建

1. 在GitHub上新建仓库

2. 根据本地项目的情况选择合适的命令

我这里是新建的一个仓库，之前本地不存在，则选择第一个

echo "# aaa" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/welitis/aaa.git
git push -u origin main             

操作命令总结

关联一个远程库

git remote add origin git@server-name:path/repo-name.git

关联后第一次推送

git push -u origin master

推送远程库

git push origin master

Git标签

◼ 对于重大的版本我们常常会打上一个标签，以表示它的重要性：
 Git 可以给仓库历史中的某一个提交打上标签；
 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）；
◼ 创建标签：
 Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）；
 附注标签：通过-a选项，并且通过-m添加额外信息；

git tag v1.0
git tag -a v1.1 -m "辅助标签"

◼ 默认情况下，git push 命令并不会传送标签到远程仓库服务器上。
 在创建完标签后你必须显式地推送标签到共享服务器上，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签；

git push origin v1.0
git push origin --tags

◼ 删除本地tag：
要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>

git tag -d v1.0

◼ 删除远程tag：
 要删除远程的tag我们可以通过git push <remote> –delete <tagname>

git push origin --delete v1.0

◼ 检出tag：
 如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令；
 通常我们在检出tag的时候还会创建一个对应的分支（分支后续了解）；

git checkout v1.0

git reset 和git revert 的区别？

a -> b -> c

c使用git reset 是直接回退到b，git历史记录中不会再存在c这个历史记录，即 a -> b，而git revert是复制要回退的版本到下一记录，即 a -> b -> c -> b，git记录中会保留c这个状态的记录

git diff ， git diff --staged 和 git diff HEAD的差别

git diff 显示当前工作区的文件和stage区文件的差异

git diff --staged 比较暂存区和已提交的本地仓库的不同

git diff HEAD 比较 HEAD指针所处区域和本地仓库的不同，即工作区被tracking文件和本地仓库的不同

为什么 Git diff HEAD 不会显示新建文件的改变？

因为git diff 只比较已经被git tracking 的文件和本地仓库中的不同，不会比较未被tracking的文件，要想能够比较，需要使用 git add 命令使新建文件被tracking

工作常见问题

在Gitlab新建了一个仓库，如何将本地代码提交到Gitlab上？

本地代码做了一些修改提交到了本地仓库，拉取远程仓库时和本地产生了冲突如何解决？

代码发布后发现出现了问题，如何回退远程仓库代码？

自己分支的代码需要合并到主分支进行提交，出现错误如何解决？

如何让一个被git管理的文件不再被控制？

git rm -r --cached ignoreFile(想要忽略的文件) 

Git常见命令速查表