本页的主要内容均转自其它博客，并结合个人经验进行了优化，仅供记录之用
本文的主要内容为：配置并初始化一个仓库（ repository ）、开始或跟踪（ track ）文件、暂存（ stage ）或提交（ commit ）更改。
此外还有：配置 Git 来忽略指定的文件和文件模式、撤销错误操作、浏览项目的历史版本、浏览不同提交（ commit ）间的差异、向远程仓库推送（ push ）以及从远程仓库拉取（ pull ）文件。
获取 Git 仓库
取得 Git 项目仓库的方法主要有两种：
- 在现有项目或目录下导入所有文件到 Git 中；
- 从一个服务器克隆（ clone ）一个现有的 Git 仓库。
在现有目录中初始化仓库
如果打算使用 Git 来对现有的项目进行管理，只需要进入该项目目录并输入：
1 | $ git init |
该命令将创建一个名为.git的目录，这个子目录含有初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。但此时项目中的文件还没有被跟踪。
如果是在一个已经存在文件的文件夹（而不是空文件夹）中初始化 Git 仓库来进行版本控制的话，应该开始跟踪这些文件并提交。可以通过git add命令来实现对指定文件的跟踪，然后执行git commit提交：
1 | $ git add *.c |
这样，就得到了一个实际维护（或者说是跟踪）着若干个文件的 Git 仓库。
克隆现有的仓库
如果想获得一份已经存在了的 Git 仓库的拷贝，这时候就需要用到git clone命令。在默认配置下，该命令会将远程 Git 仓库中的每一个文件的每一个版本都拉取下来。
克隆仓库的命令格式是git clone [url]。比如，要克隆 Git 的可链接库libgit2，可以用下面的命令：
1 | $ git clone https://github.com/libgit2/libgit2 |
这会在当前目录下创建一个名为libgit2的目录，并在这个目录下初始化一个.git文件夹，从远程仓库拉取所有数据放入.git文件夹，然后从中读取最新版本的文件的拷贝。此时所有的项目文件都已经存储在libgit2这个文件夹内了。如果想克隆远程仓库时，自定义本地仓库的名字时，可以使用如下命令：
1 | $ git clone https;//github.com/libgit2/libgit2 mylibgit |
这将执行与上一个命令相同的操作，不过在本地创建的仓库名称会变为mylibgit。
Git 支持多种数据传输协议，比如HTTP/HTTPS协议、git协议或SSH协议等。
记录每次更新到仓库
工作目录下的每一个文件必然处在已跟踪或未跟踪这两种状态之一。
已跟踪文件是指已经被纳入了版本控制的文件，在上一次快照中有它们的记录。在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。
未跟踪文件是指工作目录中除已跟踪文件以外的所有其它文件，既不存在于上次快照的记录中，也没有放入暂存区。
初次克隆某个仓库时，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。在编辑过某些文件之后，Git 会将它们标记为已修改文件。逐步将已修改文件放入暂存区，最后提交所有暂存的修改，这样就完成了一个版本更新（或文件更新循环）。使用 Git 时文件的生命周期如下：
检查当前文件状态
可以使用git status命令来查看文件状态。如果在克隆仓库后立即使用此命令，会看到类似的输出：
1 | $ git status |
这说明所有已跟踪文件在上次提交后都未被更改过，并且当前目录下没有出现任何处于未跟踪状态的新文件，以及当前所在分支的名称为master和该分支同远程服务器上对应的分支没有偏离这些信息。
如果之前并不存在README文件，那么在项目下创建一个新的README文件后，使用git status命令将会看到一个新的未跟踪文件：
1 | $ echo 'My Project' > 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命令使用文件或目录的路径作为参数，如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。
暂存已修改文件
如果修改了一个名为CONTRIBUTING.md的已跟踪的未修改文件，然后运行git status命令，会看到下面内容：
1 | $ git status |
Changes not staged for commit行表明其处于已修改状态，但未处于暂存区。要暂存这次更新，需要运行git add命令。该命令既能用于跟踪新文件，也能用于将已跟踪的已修改文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。与其说是“将一个文件添加到项目中”，不如说是“添加内容到下一次提交中”。此时运行git add CONTRIBUTING.md将其放到暂存区，然后再运行git status，会有：
1 | $ git add CONTRIBUTING.md |
现在两个文件都已暂存，下次提交时就会一并记录到仓库。但如果此时再次修改CONTRIBUTING.md，存盘后运行git status，会有：
1 | $ git status |
此时提交的话，提交的CONTRIBUTING.md是第一次修改后add上去的文件，而不是第二次修改或未修改的CONTRIBUTING.md文件（虽然未修改文件本来就不会被提交）。因此，运行了git add之后又做了修改的文件，需要再次运行git add把最新版本重新暂存起来：
1 | $ git add CONTRIBUTING.md |
状态简览
git status具有多个可选参数。比如git status -s或git status --short可以得到类似于以下这样的输出：
1 | $ git status -s |
??标记表示新添加的未跟踪文件，A标记表示新添加到暂存区中的文件，M标记表示修改过的文件。MM右边的M表示该文件被修改了但是还没有放入暂存区，右边的M表示该文件被修改了并放入了暂存区。例如，上面的状态报告显示：README文件在工作区中被修改了但还没有将修改后的文件放入暂存区，lib/simplegit.rb文件被修改了并将修改后的文件放入了暂存区，而Rakefile在工作区被修改并提交到暂存区后又在工作区中被修改了，所以在暂存区和工作区都有该文件被修改了的记录。
忽略文件
一般来说总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，可以创建一个名为.gitignore的文件，列出要忽略的文件模式。例如：
1 | $ cat .gitignore |
第一行表明 Git 会忽略所有以.o和.a结尾的文件。第二行表明 Git 会忽略所有以~结尾的文件。此外可能还有log，tmp或pid目录，以及自动生成的文档等。最好在一开始就设置好.gitignore文件的习惯，以免将来误提交这类无用的文件。
文件.gitignore的格式规范如下：
- 所有空行或以
#开头的行都会被 Git 忽略； - 可以使用标准的 glob 模式匹配；
- 匹配模式可以以（
/）开头防止递归； - 匹配模式可以以（
/）结尾指定目录； - 要忽略指定模式以外的文件或目录，可以在模式前加上
!取反。
glob 模式是指 shell 所使用的简化了的正则表达式。星号（*）匹配零个或多个任意字符；[abc]匹配任何一个列在方括号中的字符（即 a 或 b 或 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如[0-9]表示匹配所有 0 到 9 的数字）。使用两个星号（**）表示匹配任意中间目录，比如a/**/z可以匹配a/z、a/b/z或a/b/c/z等。
例如下面的.gitignore文件的例子：
1 | # 忽略所有的 .a 文件 |
小提示
GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表，该文件储存于GitHub .gitignore
一个仓库可能只在根目录下有一个.gitignore文件，它递归地应用到整个仓库中。然而，子目录下也可以有额外的.gitignore文件。子目录中的.gitignore文件中的规则只作用于它所在的目录中。具体的内容可以使用man gitignore
查看已暂存和未暂存的修改
可以使用git diff查看具体修改的地方。这将通过文件补丁的格式显示具体哪些行发生了改变。
假如再次修改README文件后暂存，然后编辑CONTRIBUTING.md文件后先不暂存， 运行status命令将会看到：
1 | $ git status |
要查看尚未暂存的文件更新了哪些部分，不加参数直接输入git diff：
1 | $ git diff |
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。也就是修改之后还没有暂存起来的变化内容。
若要查看已暂存的将要添加到下次提交里的内容，可以用git diff --staged命令。这条命令将比对已暂存文件与最后一次提交的文件差异：
1 | $ git diff |
然后用git diff --cached查看已经暂存起来的变化（--staged和--cached是同义词）：
1 | $ git diff --cached |
提交更新
现在的暂存区已经准备就绪，可以提交了。在此之前，请务必确认还有什么已修改或新建的文件还没有git add过，否则提交的时候不会记录这些尚未暂存的变化。这些已修改但未暂存的文件只会保留在本地磁盘。所以，每次准备提交前，先用git status看下，所需要的文件是不是都已暂存起来了，然后再运行提交命令git commit：
1 | $ git commit |
这样会启动指定的文本编辑器来输入提交说明。
对于 Vim 编辑器，可能会产生类似的文字信息：
1 | # Please enter the commit message for your changes. Lines starting |
可以看到，默认的提交消息包含最后一次运行git status的输出，放在注释行里，另外开头还有一个空行，以供输入提交说明。这些注释行也可以清除掉。
退出编辑器时，Git 会丢弃注释行，用输入的提交说明生成一次提交。
另外，也可以在commit命令后添加-m选项，将提交信息与命令放在同一行，如下所示：
1 | $ git commit -m "Story 182: Fix benchmarks for speed" |
这样就完成了一次提交。提交后会显示，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改过。
值得注意的是，提交时记录的是放在暂存区域的快照。 任何还未暂存文件的仍然保持已修改状态，可以在下次提交时纳入版本管理。 每一次运行提交操作，都是对项目作一次快照，以后可以回到这个状态，或者进行比较。
跳过使用暂存区域
使用暂存区域可以精心准备要提交的细节，但有些时候会显得较为繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给git commit加上-a选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add步骤：
1 | $ git status |
移除文件
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用git rm命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件，运行git status时就会在Changes not staged for commit部分（也就是未暂存清单）看到：
1 | $ rm PROJECTS.md |
然后再运行git rm记录此次移除文件的操作：
1 | $ git rm PROJECTS.md |
下一次提交时，该文件就不再纳入版本管理了。如果要删除之前修改过或已经放到暂存区的文件，则必须使用强制删除选项-f（译注：即 force 的首字母）。这是一种安全特性，用于防止误删尚未添加到快照的数据，这样的数据不能被 Git 恢复。
另外一种情况是，想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。即，想让文件保留在磁盘，但是并不想让 Git 继续跟踪。 在忘记添加.gitignore文件，不小心把一个很大的日志文件或一堆.a这样的编译生成文件添加到暂存区时，这一做法尤其有用。为达到这一目的，使用--cached选项：
1 | $ git rm --cached README |
git rm命令后面可以列出文件或者目录的名字，也可以使用glob模式。比如：
1 | $ git rm log/\*.log |
注意到星号*之前的反斜杠\，因为 Git 有它自己的文件模式扩展匹配方式，所以不用 shell 来帮忙展开。此命令删除log/目录下扩展名为.log的所有文件。类似的比如：
1 | $ git rm \*~ |
该命令会删除所有名字以~结尾的文件。
移动文件
Git 不显式跟踪文件移动操作。如果在 Git 中重命名了某个文件，仓库中存储的元数据并不会体现出这是一次改名操作。不过 Git 非常聪明，它会推断出究竟发生了什么。
要在 Git 中对文件改名，可以这么做：
1 | $ git mv file_from file_to |
示例说明：
1 | $ git mv README.md README |
其实，运行git mv就相当于运行了下面三条命令：
1 | $ mv README.md README |
如此分开操作，Git 也会意识到这是一次重命名，所以不管何种方式结果都一样。两者唯一的区别在于，git mv是一条命令而非三条命令，直接使用git mv方便得多。不过在使用其他工具重命名文件时，记得在提交前git rm删除旧文件名，再git add添加新文件名。
查看提交历史
可以使用git log命令来回顾提交历史。
以simplegit为例，运行下面的命令获取该项目：
1 | $ git clone https://github.com/schacon/simplegit-progit |
在此项目中运行git log时，可以看到下面的输出：
1 | $ git log |
在默认情况下，不传入任何参数的git log会按时间先后顺序列出所有的提交，最近的更新排在最上面。该命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮箱地址、提交时间以及提交说明。
git log有许多选项，其中一个比较有用的选项是-p或--patch，它会显示每次提交所引入的差异（按补丁的格式输出）。也可以限制显示的日志条目数量，例如使用-2选项来只显示最近的两次提交：
1 | $ git log -p -2 |
该选项除了显示基本信息之外，还附带了每次提交的变化。也可以使用--stat选项来显示每次提交的简略统计信息：
1 | $ git log --stat |
--stat选项在每次提交的下面列出所有被修改过的文件、有多少文件被修改了以及被修改过的文件的哪些行被移除或是添加了。在每次提交的最后还有一个总结。
另一个非常有用的选项是--pretty。该选项可以使用不同于默认格式的方式展示提交历史。这个选项有一些内建的子选项以供使用。比如oneline会将每个提交放在一行显示，在浏览大量的提交时非常有用。另外还有short、full和fuller选项，其展示信息的格式基本一致，但是详尽程度不一：
1 | $ git log --pretty=oneline |
而format选项可以定制记录的显示格式，通常用于后期提取分析等：
1 | $ git log --pretty=format:"%h - %an, %ar : %s" |
git log --pretty=format常用的选项
| 选项 | 说明 |
|---|---|
%H | 提交的完整哈希值 |
%h | 提交的简写哈希值 |
%T | 树的完整哈希值 |
%t | 树的简写哈希值 |
%P | 父提交的完整哈希值 |
%p | 父提交的简写哈希值 |
%an | 作者名字 |
%ae | 作者的电子邮件地址 |
%ad | 作者修订日期（可以用 –date=选项 来定制格式） |
%ar | 作者修订日期，按多久以前的方式显示 |
%cn | 提交者的名字 |
%ce | 提交者的电子邮件地址 |
%cd | 提交日期 |
%cr | 提交日期（距今多长时间） |
%s | 提交说明 |
这里的作者和提交者是存在差异的。作者是指实际做出修改的人，提交者指的是最后将此工作成果提交到仓库的人。所以当 A 为某个项目发布补丁，而 B 将此补丁并入项目中时，A 就是作者，而 B 就是提交者。
当oneline或format与另一个log选项--graph结合使用时尤其有用。这个选项添加了一些 ASCII 字符串来形象地展示分支、合并历史：
1 | $ git log --pretty=format:"%h %s" --graph |
git log 的常用选项
| 选项 | 说明 |
|---|---|
-p | 按补丁格式显示每个提交引入的差异 |
--stat | 显示每次提交的文件修改统计信息 |
--shortstat | 只显示 –stat 中最后的行数修改添加移除统计 |
--name-only | 仅在提交信息后显示已修改的文件清单 |
--name-status | 显示新增、修改、删除的文件清单 |
--abbrev-commit | 仅显示 SHA-1 校验和所有 40 个字符中的前几个字符 |
--relative-date | 使用较短的相对时间而不是完整格式显示日期（比如“2 weeks ago”） |
--graph | 在日志旁以 ASCII 图形显示分支与合并历史 |
--pretty | 使用其他格式显示历史提交信息。可用的选项包括 oneline、short、full、fuller 和 format（用来定义自己的格式） |
--oneline | --pretty=oneline --abbrev-commit 合用的简写 |
限制输出长度
除了定制输出格式的选项之外，git log还有许多非常实用的限制输出长度的选项，也就是只输出一部分的提交。除了上面提到的-2以外，还有其它类似的选项。比如下面的命令会列出最近两周的所有提交：
1 | $ git log --since=2.weeks |
该命令可用的格式十分丰富——可以是类似"2008-01-15"的具体的某一天，也可以是类似"2 years 1 day 3 minutes ago"的相对日期。
还可以过滤出匹配指定条件的提交。用--author选项显示指定作者的提交，用--grep选项搜索提交说明中的关键字。
可以指定多个 --author 和 --grep 搜索条件，这样会只输出匹配 任意 --author 模式和 任意 --grep 模式的提交。然而，如果添加了 --all-match 选项， 则只会输出匹配 所有 --grep 模式的提交
另一个非常有用的过滤器是-S，它接受一个字符串参数，并且只会显示那些添加或删除了该字符串的提交。 如果想找出添加或删除了对某一个特定函数的引用的提交，可以调用：
1 | $ git log -S function_name |
最后一个很实用的git log选项是路径（path），如果只关心某些文件或者目录的历史提交，可以在git log选项的最后指定它们的路径。因为是放在最后位置上的选项，所以用两个短划线（–）隔开之前的选项和后面限定的路径名。
限制 git log 输出的选项
| 选项 | 说明 |
|---|---|
-<n> | 仅显示最近的 n 条提交 |
--since, --after | 仅显示指定时间之后的提交 |
--until, --before | 仅显示指定时间之前的提交 |
--author | 仅显示作者匹配指定字符串的提交 |
--committer | 仅显示提交者匹配指定字符串的提交 |
--grep | 仅显示提交说明中包含指定字符串的提交 |
-S | 仅显示添加或删除内容匹配指定字符串的提交 |
如果要在 Git 源码库中查看 Junio Hamano 在 2008 年 10 月期间，除了合并提交之外的哪一个提交修改了测试文件，可以使用下面的命令：
1 | $ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \ |
在近 40000 条提交中，上面的输出仅列出了符合条件的 6 条记录。
隐藏合并提交
由于记录中可能会包含为数不少的提交，其包含的信息却不多。为了避免显示的合并提交弄乱历史记录，可以为log加上--no-merges选项
撤销操作
当提交完后发现有漏掉的文件没有添加，或者提交信息写错了。那么可以运行带有--amend选项的提交命令来重新提交：
1 | $ git commit --amend |
这个命令会将暂存区中的文件提交。如果自上次提交以来还未做任何修改，那么快照会保持不变，而修改的只是提交信息。
文本编辑器启动后，可以看到之前的提交信息。编辑后保存会覆盖原来的提交信息。
例如：
1 | $ git commit -m 'initial commit' |
在运行以上内容后，最终只会有一个提交，第二次提交会代替第一次提交的结果。
使用此方法修补最后的提交时，从效果上来说，就像是旧提交从未存在过一样，它并不会出现在仓库的历史中
修补提交最明显的价值是可以小范围改进最后的提交，而不会使提交信息弄乱仓库历史
取消暂存的文件
有些命令在修改文件状态的同时，也会提示如何进行撤销操作。例如，想对已经修改了的两个文件分两次独立的修改提交，但是却意外地输入git add *暂存了它们两个。而使用git status命令则会显示取消暂存的方法：
1 | $ git add * |
在Changes to be committed文字正下方，提示使用git reset HEAD <file>...来取消暂存。所以可以使用以下命令来取消暂存CONTRIBUTING.md文件：
1 | $ git reset HEAD CONTRIBUTING.md |
这样，CONTRIBUTING.md文件已经是修改未暂存的状态了。
git reset是一个比较危险的命令，如果加上了--hard选项则更是危险。然而上述情况中，工作目录中的文件尚未修改，因此相对安全一些
撤销对文件的修改
如果不想保留对CONTRIBUTING.md文件的修改，使用git status命令则会显示取消修改的方法：
1 | Changes not staged for commit: |
在Changes not staged for commit文字正下方，提示使用git checkout -- <file>...来取消暂存。所以可以使用以下命令来取消暂存CONTRIBUTING.md文件：
1 | $ git checkout -- CONTRIBUTING.md |
git checkout -- <file>也是一个危险的命令。这会使得那个文件在本地的任何修改都会消失—— Git 会用最近提交的版本覆盖掉它
除非确定不需要那个文件的本地修改，否则不要运行该命令
在 Git 中任何已提交的东西几乎总是可以恢复的。甚至在被删除的分支中提交或使用--amend选项覆盖的提交也可以恢复。然而未提交的文件丢失后就很可能再也找不到了
远程仓库的使用
为了能在任意 Git 项目上协作，需要知道如何管理自己的远程仓库。远程仓库一般是指托管在因特网或其他网络中的项目的版本库。每个人可以有好几个远程仓库，对于不同的使用者，有些仓库是只读的，有些则是可以读写。与他人协作涉及管理远程仓库以及根据需要推送或拉取数据。管理远程仓库包括了解如何添加远程仓库、移除无效的远程仓库、管理不同的远程分支并定义它们是否被跟踪等等。
远程仓库可以部署在本地主机上
远程仓库中的“远程”是相对于本地工作路径中的“本地”，只是用来表示存在于别处。使用本地主机和使用其它远程仓库一样，都需要一样的标准推送、拉取和抓取操作
查看远程仓库
如果想查看已经配置的远程仓库服务器，可以运行git remote命令。它将列出其指定的每一个远程服务器的简写。如果已经克隆了自己的仓库，那么至少应该能看到origin——这是 Git 对克隆的仓库服务器的默认名字：
1 | $ git clone https://github.com/schacon/ticgit |
也可以指定选项-v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL：
1 | $ git remote -v |
如果远程仓库不止一个，该命令会将它们全部列出。例如，与几个协作者合作的，拥有多个远程仓库的仓库看起来像下面这样：
1 | $ cd grit |
添加远程仓库
运行git remote add <shortname> <url>添加一个新的远程 Git 仓库，同时指定一个方便使用的简写：
1 | $ git remote |
现在可以在命令行中使用字符串pb来代替整个 URL。例如想拉取 Paul 的仓库中有但此处没有的信息，可以运行git fetch pb：
1 | $ git fetch pb |
现在 Paul 的 master 分支可以在本地通过pb/master访问到——可以将它合并到自己的某个分支中， 或者如果想要查看它的话，可以检出一个指向该点的本地分支。
从远程仓库中抓取与拉取
从远程仓库中获得数据，可以执行：
1 | $ 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> 命令。如果想以一个特定的缩写名运行这个命令，例如 origin ，会得到像下面类似的信息：
1 | $ git remote show origin |
它同样会列出远程仓库的 URL 与跟踪分支的信息。 这些信息非常有用，它告诉你正处于 master 分支，并且如果运行 git pull， 就会抓取所有的远程引用，然后将远程 master 分支合并到本地 master 分支。 它也会列出拉取到的所有远程引用。
此外，还可以通过 git remote show 看到更多的信息：
1 | $ git remote show origin |
这个命令列出了当你在特定的分支上执行 git push 会自动地推送到哪一个远程分支。 它也同样地列出了哪些远程分支不在你的本地，哪些远程分支已经从服务器上移除了， 还有当你执行 git pull 时哪些本地分支可以与它跟踪的远程分支自动合并。
远程仓库的重命名与移除
你可以运行 git remote rename 来修改一个远程仓库的简写名。 例如，想要将 pb 重命名为 paul，可以用 git remote rename 这样做：
1 | $ git remote rename pb paul |
值得注意的是这同样也会修改你所有远程跟踪的分支名字。 那些过去引用 pb/master 的现在会引用 paul/master。
如果因为一些原因想要移除一个远程仓库——你已经从服务器上搬走了或不再想使用某一个特定的镜像了， 又或者某一个贡献者不再贡献了——可以使用 git remote remove 或 git remote rm ：
1 | $ git remote remove paul |
一旦使用这种方式删除了一个远程仓库，那么所有和这个远程仓库相关的远程跟踪分支以及配置信息也会一起被删除。
打标签
像其他版本控制系统（VCS）一样，Git 可以给仓库历史中的某一个提交打上标签，以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）。 在本节中，你将会学习如何列出已有的标签、如何创建和删除新的标签、以及不同类型的标签分别是什么。
列出标签
在 Git 中列出已有的标签非常简单，只需要输入 git tag （可带上可选的 -l 选项 --list）：
1 | $ git tag |
这个命令以字母顺序列出标签，但是它们显示的顺序并不重要。
你也可以按照特定的模式查找标签。 例如，Git 自身的源代码仓库包含标签的数量超过 500 个。 如果只对 1.8.5 系列感兴趣，可以运行：
1 | $ git tag -l "v1.8.5*" |
按照通配符列出标签需要 -l 或 --list 选项如果你只想要完整的标签列表，那么运行 git tag 就会默认假定你想要一个列表，它会直接给你列出来， 此时的 -l 或 --list 是可选的。然而，如果你提供了一个匹配标签名的通配模式，那么 -l 或 --list 就是强制使用的
创建标签
Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。
轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。
而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。 通常会建议创建附注标签，这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签， 或者因为某些原因不想要保存这些信息，那么也可以用轻量标签。
附注标签
在 Git 中创建附注标签十分简单。 最简单的方式是当你在运行 tag 命令时指定 -a 选项：
1 | $ git tag -a v1.4 -m "my version 1.4" |
-m 选项指定了一条将会存储在标签中的信息。 如果没有为附注标签指定一条信息，Git 会启动编辑器要求你输入信息。
通过使用 git show 命令可以看到标签信息和与之对应的提交信息：
1 | $ git show v1.4 |
输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。
轻量标签
另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：
1 | $ git tag v1.4-lw |
这时，如果在标签上运行 git show，你不会看到额外的标签信息。 命令只会显示出提交信息：
1 | $ git show v1.4-lw |
后期打标签
你也可以对过去的提交打标签。 假设提交历史是这样的：
1 | $ git log --pretty=oneline |
现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。 你可以在之后补上标签。 要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）：
1 | $ git tag -a v1.2 9fceb02 |
可以看到你已经在那次提交上打上标签了：
1 | $ git tag |
共享标签
默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样——你可以运行 git push origin <tagname>。
1 | $ git push origin v1.5 |
如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。 这将会把所有不在远程仓库服务器上的标签全部传送到那里。
1 | $ git push origin --tags |
现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。
git push 推送两种标签使用 git push <remote> --tags 推送标签并不会区分轻量标签和附注标签， 没有简单的选项能够让你只选择推送一种标签
删除标签
要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>。 例如，可以使用以下命令删除一个轻量标签：
1 | $ git tag -d v1.4-lw |
注意上述命令并不会从任何远程仓库中移除这个标签，你必须用 git push <remote> :refs/tags/<tagname> 来更新你的远程仓库：
第一种变体是 git push <remote> :refs/tags/<tagname> ：
1 | $ git push origin :refs/tags/v1.4-lw |
上面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。
第二种更直观的删除远程标签的方式是：
1 | $ git push origin --delete <tagname> |
检出标签
如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令， 虽然这会使你的仓库处于“分离头指针（detached HEAD）”的状态——这个状态有些不好的副作用：
1 | $ git checkout 2.0.0 |
在“分离头指针”状态下，如果你做了某些更改然后提交它们，标签不会发生变化， 但你的新提交将不属于任何分支，并且将无法访问，除非通过确切的提交哈希才能访问。 因此，如果你需要进行更改，比如你要修复旧版本中的错误，那么通常需要创建一个新分支：
1 | $ git checkout -b version2 v2.0.0 |
如果在这之后又进行了一次提交，version2 分支就会因为这个改动向前移动， 此时它就会和 v2.0.0 标签稍微有些不同，这时就要当心了。
Git 别名
在我们结束本章 Git 基础之前，正好有一个小技巧可以使你的 Git 体验更简单、容易、熟悉：别名。 我们不会在之后的章节中引用到或假定你使用过它们，但是你大概应该知道如何使用它们。
Git 并不会在你输入部分命令时自动推断出你想要的命令。 如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。 这里有一些例子你可以试试：
1 | $ git config --global alias.co checkout |
这意味着，当要输入 git commit 时，只需要输入 git ci。 随着你继续不断地使用 Git，可能也会经常使用其他命令，所以创建别名时不要犹豫。
在创建你认为应该存在的命令时这个技术会很有用。 例如，为了解决取消暂存文件的易用性问题，可以向 Git 中添加你自己的取消暂存别名：
1 | $ git config --global alias.unstage 'reset HEAD --' |
这会使下面的两个命令等价：
1 | $ git unstage fileA |
这样看起来更清楚一些。 通常也会添加一个 last 命令，像这样：
1 | $ git config --global alias.last 'log -1 HEAD' |
这样，可以轻松地看到最后一次提交：
1 | $ git last |
可以看出，Git 只是简单地将别名替换为对应的命令。 然而，你可能想要执行外部命令，而不是一个 Git 子命令。 如果是那样的话，可以在命令前面加入 ! 符号。 如果你自己要写一些与 Git 仓库协作的工具的话，那会很有用。 我们现在演示将 git visual 定义为 gitk 的别名：
1 | $ git config --global alias.visual '!gitk' |
