本篇文章涵盖你在使用 Git 完成各种工作时将会用到的各种基础命令。通过这篇文章，将学习配置并初始化一个仓库（respository），开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。这篇文章也将演示如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作，如何浏览你的项目的历史版本以及不同提交间的差异、如何向你的远程仓库推送（push）以及如何从你的仓库拉取（pull）文件。
获取 Git 仓库
有两种取得 Git 项目仓库的方式：
- 将尚未进行版本控制的本地目录转换为 Git 仓库
- 从其它服务器克隆一个已存在的 Git 仓库
两种方式都会在你的本地机器上得到一个工作就绪的 Git 仓库。
在已存在目录中初始化仓库
如果你有一个尚未进行版本控制的项目目录，想要用 Git 来控制它，那么首先需要进入该项目目录中，之后执行 git init 命令。
1 | # cd my_project/ |
该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。但是，在这个时候，我们仅仅是做了一个初始化的操作，项目里的文件还没有被跟踪。
如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，你应该开始追踪这些文件并进行初始提交。可以通过 git add 命令来指定所需的文件来进行追踪，然后执行 git commit：
1 | # git add *.c |
现在，你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。
克隆现有的仓库
如果你想获得一份已经存在了的 Git 仓库的拷贝，这时就要用到 git clone 命令。如果你对其它的 VCS 系统（例如 Subversion）很熟悉，需要注意这里用到的命令是 clone 而不是 checkout。这是 Git 区别于其它版本控制系统的一个重要特性，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。
当你执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库。
克隆仓库的命令是 git clone <url>， 比如，要克隆 Git 的链接库 libgit2，可以用下面的命令:
1 | git clone https://github.com/libgit2/libgit2 |
这会在当前目录下创建一个名为 libgit2 的目录，并在这个目录下初始化一个 .git 文件夹， 从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。
如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以通过额外的参数指定新的目录名：
1 | git clone https://github.com/libgit2/libgit2 mylibgit |
Git 支持多种数据传输协议。 上面的例子使用的是 https:// 协议，不过你也可以使用 git:// 协议或者使用 SSH 传输协议，比如 user@server:path/to/repo.git。
记录每次更新到仓库
现在我们的机器上有了一个真实项目的 Git 仓库，并从这个仓库中检出了所有文件的工作副本。通常，你会对这些文件做些修改，每当完成了一个阶段的目标，想要记录下它时，就需要将它提交到到仓库。
请记住，你工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能是未修改、已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。
工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入 暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们，而你尚未编辑过它们。
编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。
如下显示了使用 Git 时文件的生命周期：
检查当前状态
可以用 git status 命令查看哪些文件处于什么状态。如果在克隆仓库后立即使用此命令，会看到类似这样的输出:
1 | # git status |
这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。
现在，让我们在项目下创建一个新的 README 文件，使用 git status 命令，你将看到一个新的未跟踪文件:
1 | # touch README |
在状态报告中可以看到新建的 README 文件出现在 Untracked files 下面。 未跟踪的文件意味着 Git 在之前的快照（提交）中没有这些文件。Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它 我需要跟踪该文件。这样的处理让你不必担心将生成的二进制文件或其它不想被跟踪的文件包含进来。
跟踪新文件
使用命令 git add 开始跟踪一个文件。所以，要跟踪 README 文件，运行：
1 | # git add README |
此时再运行 git status 命令，会看到 README 文件已被跟踪，并处于暂存状态:
1 | # git status |
只要在 Changes to be committed 这行下面的，就说明是已暂存状态。如果此时提交，那么该文件在你运行 git add 时的版本将被留存在后续的历史记录中。git add 命令使用文件或目录的路径作为参数。如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。
暂存已修改文件
如果修改一个已跟踪文件，例如这里假设是 LISCENCE 这个已被跟踪文件，然后运行 git status 命令，将看到下面内容：
1 | # git status |
此时，LICENSE 文件出现在 Changes not staged for commit 这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。要暂存这次更新，需要运行 git add 命令：
1 | # git add LICENSE |
git add 是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。可以将这个命令理解为 精确地将内容添加到下一次提交中。在暂存 LICENSE 文件之后，再次运行 git status 命令，得到如下输出：
1 | # git status |
现在两个文件都已暂存，下次提交时就会一并记录到仓库。假如此时，你又修改了 LICENSE 文件，再次使用 git status 查看：
1 | # git status |
此时，LICENSE 文件同时出现在暂存区和非暂存区。这是因为：Git 只是暂存了你运行 git add 命令时的版本，如果你现在提交，提交的 LICENSE 的版本是你最后一次运行 git add 命令时的那个版本，而不是你运行 git commit 时，在工作目录中的当前版本。所以，如果运行了 git add 之后又修改了文件，需要重新运行 git add 把最新版本重新暂存起来：
1 | # git add LICENSE |
状态简览
git status 命令的输出十分详细，但其用语有些繁琐。可以使用 git status -s 命令或 git status --short 获得一种更为紧凑的格式输出。
1 | # git status -s |
新添加的未跟踪文件前面有 ?? 标记，新添加到暂存区中的文件前面有 A 标记，修改过的文件前面有 M 标记。 输出中有两栏，左栏指明了暂存区的状态，右栏指明了工作区的状态。因此如果某个文件出现了 MM 标记，表示该文件的修改中既有已暂存的部分，又有未暂存的部分。
忽略文件
一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式。要养成一开始就为你的新仓库设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。 来看一个实际的 .gitignore 例子：
1 | # cat .gitignore |
文件 .gitignore 的格式规范如下：
- 所有空行或者以 # 开头的行都会被 Git 忽略
- 可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中（glob 模式是指 shell 所使用的简化了的正则表达式）
- 匹配模式可以以 / 开头防止递归
- 匹配模式可以以 / 结尾指定目录
- 要忽略指定模式以外的文件或目录，可以在模式前加上叹号 ! 取反
在最简单的情况下，一个仓库可能只根目录下有一个 .gitignore 文件，它递归地应用到整个仓库中。 然而，子目录下也可以有额外的 .gitignore 文件。子目录中的 .gitignore 文件中的规则只作用于它所在的目录中。
查看已暂存和未暂存的修改
经常我们需要知道 当前做的哪些更新还没有暂存 以及有哪些更新已经暂存起来准备好下次提交。尽管 git status 已经通过在相应栏下列出文件名的方式回答了这些问题，但 git diff 能通过文件补丁的格式更加具体地显示哪些行发生了改变。
要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff。此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。 也就是修改之后还没有暂存起来的变化内容。
若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --staged 或者 git diff --cached 命令。这条命令将比对已暂存文件与最后一次提交的文件差异：
1 | # git diff --staged |
请注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。所以有时候你一下子暂存了所有更新过的文件，运行 git diff 后却什么也没有，就是这个原因。
这里，我们是使用 git diff 来分析文件差异。但是，如果你喜欢图形化的工具或外部 diff 工具来比较差异，可以使用 git difftool 命令来调用 vimdiff 等软件输出 diff 分析结果。
提交更新
暂存区域准备就绪后，就可以提交了。每次提交前，最好先用 git status 看下，是不是所需要的文件都已暂存起来了，然后再运行提交命令 git commit。这种方式会启动你选择的文本编辑器来输入提交说明。
编辑器会显示类似下面的文本信息(本例选用 Vim 的屏显方式展示):
1 | # Please enter the commit message for your changes. Lines starting |
默认的提交信息包含最后一次运行 git status 的输出，放在注释行里。另外开头还有一空行，供你输入提交说明。可以去掉这些注释行，不过留着也没关系，它能帮你回想起这次更新的内容有哪些。退出编辑器时，Git 会丢弃注释行，用你输入的提交说明生成一次提交。
如果想要更详细的对修改了哪些内容的提示，可以用 -v 选项，它会将你所做改变的diff输出放到编辑器中，从而使你知道本次提交具体做了哪些修改。退出编辑器时，Git会丢掉注释行，用你输入的提交信息生成一次提交。
另外，你也可以在 commit 命令后添加 -m 选项，将提交信息与命令放在同一行：
1 | # git commit -m "initial commit" |
提交后 git 会告诉你，当前是在哪个分支提交的（这里是 master），本次提交的完整 SHA-1 校验和是什么（这里是 3af4deb），以及在本次提交中有哪些文件修订过、多少行添加和删改过。
需要记住，提交时记录的是放在暂存区域的快照，任何还未暂存文件的仍然保持已修改状态。每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。
跳过使用暂存区域
尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式， 只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤。
移除文件
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用 git rm 命令完成此项工作，该命令同时在工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 部分看到该文件：
1 | # rm -rf README |
然后再运行 git rm 记录此次移除文件的操作：
1 | # git status |
下次提交时，该文件就不再纳入版本管理了。如果要删除的文件被修改过但该修改还没有放到暂存区域的话，则必须用强制删除选项 -f。这是一种安全特性，用于防止误删还没有添加到快照的数据，这样的数据不能被 Git 恢复。
1 | # git rm LICENSE |
另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。为达到这一目的，使用 –cached 选项。
git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。
移动文件
不像其他 VCS 系统，git 并不显式跟踪文件移动操作。如果在 Git 中重命名了某个文件，仓库中存储的元数据并不会体现出这是一次改名操作。但是 Git 可以自动推断出发生了什么。要在 Git 中对文件改名，可以使用 git mv 命令：
1 | # git mv LICENSE MY_LICENSE |
此时查看状态信息，也会看到关于重命名操作的说明：
1 | # git status |
其实，运行 git mv 命令相当于运行了下面三条命令：
1 | mv LICENSE MY_LICENSE |
如此分开操作，Git 也会意识到这是一次重命名，所以不管何种方式结果都一样。 两者唯一的区别是，mv 是一条命令而非三条命令，直接用 git mv 方便得多。
查看提交历史
在提交了若干更新，又或者克隆了某项目之后，你也许想回顾一下提交历史。完成这个任务最简单有效的工具是 git log 命令。
1 | # git log |
不传入任何参数的默认情况下，git log 会按时间先后顺序列出所有的提交，最近的更新排在最上面。这个命令会列出每次提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。
git log 有许多选项可以帮助你搜寻你所要找的提交，下面我们会介绍几个最常用的选项：
- -p：显示每次提交所引入的差异（按补丁的格式输出）
- -num：用来显示最新的 num 次提交，例如 -2
- –stat：查看每次提交的简略统计信息。包括所有被修改过的文件以及被修改过文件的哪些行被移除或是被添加了
- –pretty：这个选项可以使用不同于默认格式的方式展示提交历史。该选项有一些内建的子选项供你使用。 比如 oneline 会将每个提交放在一行显示，在浏览大量的提交时非常有用。另外还有 short，full 和 fuller 选项，它们展示信息的格式基本一致，但是详尽程度不一。另外 format 可以定制记录的显示格式，这样的输出对后期提取分析格外有用
- –graph：这个选项添加了一些 ASCII 字符串来形象地展示你的分支、合并历史。当该选项与oneline 或 format结合使用时，尤其有用
限制输出长度
除了定制输出格式的选项之外，git log 还有许多非常实用的限制输出长度的选项，也就是只输出一部分的提交。
- -
：仅显示最近的若干条提交 - –since，–after：仅显示指定时间之后的提交
- –until，–before：仅显示指定时间之前的提交
- –author：显示指定作者的提交
- –grep：搜索提交说明中的关键字。注意，如果要得到同时满足两个搜索条件的提交，就必须使用 –all-match 选项。否则满足任意一个条件的提交都会被匹配出来
- -S：列出那些添加或移除某些字符串的提交。如果你想找出添加或移除了某一特定函数引用的提交，可以这样使用
git log -S function_name - –no-merges：按照你代码仓库的工作流程，记录中可能有为数不少的合并提交，它们所包含的信息通常并不多。为了避免显示的合并提交弄乱历史记录，可以使用该选项
- 路径选项：如果只关心某些文件或者目录的历史提交，可以在
git log选项的最后指定它们的路径。因为是放在最后位置上的选项，所以用两个短划线 – 隔开之前的选项和后面限定的路径名
撤销操作
在任何一个阶段，你都有可能想要撤消某些操作。接下来将会学习几个撤消你所做修改的基本工具。注意有些撤销操作是不可逆的，这是在 Git 使用过程中，会因为操作失误而导致之前工作丢失的少有的几个地方之一。
有时候我们提交完了，才发现漏掉了几个文件没有添加、或者提交信息写错了。此时可以运行带有 --amend 选项的提交命令尝试重新提交：
1 | git commit --amend |
这个命令会将暂存区中的文件提交。如果自上次提交以来你还未做任何修改，那么快照会保持不变，而你所修改的只是提示信息。文本编辑器启动后，可以看到之前的提交信息。编辑后保存会覆盖原来的提交信息。最终你只会有一个提交，第二次提交将替代第一次提交的结果。修补提交最明显的价值是可以稍微改进你最后的提交。
取消暂存的文件
接下来将演示如何操作暂存区与工作目录中已修改的文件。使用 git reset HEAD <file>... 来取消暂存。如下所示，LICENSE 被修改且已经被暂存等待提交：
1 | # git status |
运行如下命令，取消对 LICENSE 文件的暂存，可以看到运行该命令之后文件处于修改未暂存状态：
1 | # git reset HEAD LICENSE |
撤消对文件的修改
如果不想保留对 LICENSE 文件的修改，向将它还原成上次提交时的样子，可以使用 git checkout -- <file> 命令：
1 | # git checkout -- LICENSE |
可以看到本地修改已经被撤消了。请务必记得 git checkout -- <file> 是一个危险的命令。你对该文件在本地的任何修改都会消失：Git 会用最近提交的版本覆盖掉它。除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。记住，在 Git 中任何已提交的东西几乎总是可以恢复的。甚至那些被删除的分支中的提交或使用 –amend 选项覆盖的提交也可以恢复。然而，任何你未提交的东西丢失后很可能再也找不到了。
如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，可以通过 Git 分支保存进度与分支，这通常是更好的做法。
远程仓库的使用
为了能在任意 Git 项目上协作，你需要知道如何管理自己的远程仓库。远程仓库是指托管在因特网或其他网络中的你的项目的版本库。你可以有好几个远程仓库，通常有些仓库对你只读，有些则可以读写。与他人协作涉及管理远程仓库以及根据需要推送或拉取数据。
其实更准确地说，远程仓库也可以在你的本地主机上，词语远程未必表示仓库在网络或互联网上的其它位置，而只是表示它在别处。在这样的远程仓库上工作，仍然需要和其它远程仓库上一样的标准推送、拉取和抓取操作。
查看远程仓库
如果想查看你已经配置的远程仓库服务器，可以运行 git remote 命令。 它会列出你指定的每一个远程服务器的简写。如果你已经克隆了自己的仓库，那么至少应该能看到 origin——这是 Git 给你克隆的仓库服务器的默认名字：
1 | # git remote |
如果指定选项 -v，会显示需要读写远程仓库时可使用的 Git 保存的简写与其对应的 URL。
1 | # git remote -v |
如果你的远程仓库不止一个，该命令会将它们全部列出。
添加远程仓库
之前已经介绍并展示了 git clone 命令是如何自行添加远程仓库的，其实也可以自行添加远程仓库，运行 git remote add <shortname> <url> 添加一个新的远程 Git 仓库，同时指定一个方便使用的简写：
1 | # git remote -v |
之后可以在命令行中使用简写字符串来代替整个 URL。例如如果你想拉取 Paul 的仓库中有但你没有的信息，可以运行 git fetch pb
1 | # git fetch pb |
现在 Paul 的 master 分支可以在本地通过 pb/master 访问到——你可以将它合并到自己的某个分支中，或者如果你想要查看它的话，可以检出一个指向该点的本地分支。
从远程仓库中抓取与拉取
从远程仓库中获得数据，可以执行 git fetch <remote>。该命令会访问远程仓库，从中拉取所有你还没有的数据。执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。
如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 origin 为简写。所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。必须注意 git fetch 命令只会将数据下载到你的本地仓库——它并不会自动合并或修改你当前的工作。当准备好时你必须手动将其合并入你的工作。
如果你的当前分支设置了跟踪远程分支，那么可以用 git pull 命令来自动抓取并合并该远程分支到当前分支。默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或其它名字的默认分支）。 运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。
推送到远程仓库
当你想分享你的项目时，必须将其推送到上游，使用的命令为 git push <remote> <branch>。 当你想要将 master 分支推送到 origin 服务器时（再次说明，克隆时通常会自动帮你设置好那两个名字）， 那么运行这个命令就可以将你所做的备份到服务器：
1 | # git push origin master |
只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。当你和其他人在同一时间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。你必须先抓取他们的工作并将其合并进你的工作后才能推送。
查看某个远程仓库
如果想要查看某一个远程仓库的更多信息，可以使用 git remote show <remote> 命令。例如：
1 | # git remote show origin |
远程仓库的重命名与移除
你可以运行 git remote rename 来修改一个远程仓库的简写名，需要注意，这同样也会修改你所有远程跟踪的分支名字。
1 | # git remote |
如果想要移除一个远程仓库，可以使用 git remote remove 或 git remote rm，如下所示：
1 | # git remote remove paul |
一旦你使用这种方式删除了一个远程仓库，那么所有和这个远程仓库相关的远程跟踪分支以及配置信息也会一起被删除。
打标签
像其他版本控制系统（VCS）一样，Git 可以给仓库历史中的某一个提交打上标签，以示重要。比较有代表性的是人们使用这个功能来标记发布结点。
列出标签
git tag（可带上可选的 -l 选项 –list）命令可以在 Git 中列出已有的标签。你也可以按照特定的模式查找标签，如果你提供了一个匹配标签名的通配模式，那么 -l 或 –list 就是强制使用的。例如：
1 | # git tag -l v0.3* |
创建标签
Git 支持两种标签：
- 轻量标签（lightweight）
- 附注标签（annotated）
轻量标签很像一个不会改变的分支，它只是某个特定提交的引用。附注标签是存储在 Git 数据库中的一个完整对象，它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间，此外还有一个标签信息，并且可以使用 GNU Privacy Guard（GPG）签名并验证。使用 git show 命令可以看到标签信息和与之对应的提交信息。
创建附注标签
在 Git 中创建附注标签十分简单。 最简单的方式是当你在运行 tag 命令时指定 -a 选项：
1 | # git tag -a v1.0 -m "my version 1.0" |
-m 选项指定了一条将会存储在标签中的信息。如果没有为附注标签指定一条信息，Git 会启动编辑器要求你输入信息。
创建轻量标签
轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字。
1 | # git tag v1.0-lw |
如果在轻量级标签上运行 git show，你不会看到额外的标签信息。命令只会显示出提交信息。
后期打标签
你也可以对过去的提交打标签。例如在下面的例子中，如果想在 quick test 那次提交之后打上标签，只需要在命令的末尾指定提交的校验和（或部分校验和）：
1 | # git log --pretty=oneline |
1 | # git tag -a v2.0 c8537f068be5540a0c703fcc0b9c6acac7c7bddf |
共享标签
默认情况下，git push 命令并不会传送标签到远程仓库服务器上。在创建完标签后你必须显式地推送标签到共享服务器上。这个过程就像共享远程分支一样：可以运行 git push origin <tagname>。如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。这将会把所有不在远程仓库服务器上的标签全部传送到那里。这样，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。
删除标签
要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>。注意该命令并不会从任何远程仓库中移除这个标签，你必须用 git push <remote> :refs/tags/<tagname> 来更新你的远程仓库。该操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。另外一种更直观的删除远程标签的方式是：
1 | git push origin --delete <tagname> |
检出标签
如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令，虽然这会使你的仓库处于 分离头指针(detacthed HEAD) 的状态（该状态会有些副作用）。
在 分离头指针 状态下，如果你做了某些更改然后提交它们，标签不会发生变化，但你的新提交将不属于任何分支，并且将无法访问，除非通过确切的提交哈希才能访问。 因此，如果你需要进行更改，比如你要修复旧版本中的错误，那么通常需要创建一个新分支。
如下基于标签 v2.0 创建新分支 version2：
1 | # git checkout -b version2 v2.0 |
如果在这之后又进行了一次提交，version2 分支就会因为这个改动向前移动，此时它就会和 v2.0.0 标签稍微有些不同。
Git 别名
Git 并不会在你输入部分命令时自动推断出你想要的命令。如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。如下是一些例子：
1 | git config --global alias.co checkout |
Git 别名在创建你认为应该存在的命令时也很有用。例如，为了解决取消暂存文件的易用性问题，可以向 Git 中 添加你自己的取消暂存别名：
1 | git config --global alias.unstage 'reset HEAD --' |
Git 只是简单地将别名替换为对应的命令。如果想要执行外部命令，而不是一个 Git 子命令，可以在命令前面加入 ! 符号。 例如将 git visual 定义为 gitk 的别名：
1 | git config --global alias.visual '!gitk' |