Git基础：第一、二章 Git简介&Git基础命令

01 第一章 Git简介

1.1 版本控制

1.1.1 什么是版本控制系统

1.1.2 集中式版本控制vs分布式版本控制系统

1.2 Git简介和历史

1.3 Git的安装

1.3.4 初次运行Git的配置

1.4 相关学习资源

02 第二章 Git基础命令

2.0 前言

能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。
演示了如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览项目的历史版本以及不同提交（commits）之间的差异、如何向远程仓库推送（push）以及别人呢如何从远程仓库拉取（pull）文件。

2.1 获取 Git 仓库

两种获取 Git 项目仓库的方式：
1、把 尚未进行版本控制的本地目录 转换为 Git 仓库；
2、从其它服务器 克隆 一个已存在的 Git 仓库。
结果：会在本地机器上得到一个工作就绪的 Git 仓库
在 已存在目录中 初始化仓库：如果有一个尚未进行版本控制的项目目录，想要用 Git 来控制它，那么首先需要进入该项目目录中。

在 Windows 上：
$ cd /c/user/my_project

之后执行：

$ git init
# 创建一个名为 .git 的子目录，这个子目录含有初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。 但是，在这个时候，我们仅仅是做了一个初始化的操作，项目里的文件还没有被跟踪。

如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，你应该开始追踪这些文件并进行初始提交。 可以通过 git add 命令来 指定所需的文件 来进行追踪，然后执行 git commit：

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

现在，已经得到了一个存在被追踪文件、初始提交的 Git 仓库。
克隆现有的仓库 ：
获得一份已经存在了的 Git 仓库的拷贝，比如说，你想为某个开源项目贡献自己的一份力，这时就要用到 git clone 命令(是"clone"而不是"checkout")，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。
当执行 git clone 命令的时候，默认配置下 远程 Git 仓库中的每一个文件 的每一个版本 都将被拉取pull下来。 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库 （虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在，详见 在服务器上搭建 Git ）。
克隆仓库的命令是 git clone 。

要克隆 Git 的链接库 libgit2，可以用下面的命令：
$ git clone https://github.com/libgit2/libgit2

这会在当前目录下创建一个名为 “libgit2” 的目录，并在这个目录下初始化一个 .git 文件夹， 从远程仓库拉取pull下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 libgit2 文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。

想在克隆远程仓库的时候，自定义本地仓库的名字，可以通过额外的参数指定新的目录名：

$ git clone https://github.com/libgit2/libgit2 mylibgit

这会执行与上一条命令相同的操作，但目标目录名变为了 mylibgit。

2.2 记录每次更新 到仓库

现在我们的机器上有了一个 真实项目 的 Git 仓库，并从这个仓库中检出了所有文件的 工作副本。 通常，我们会对这些文件做些修改，每当完成了一个阶段的目标，想要将记录下它时，就将它提交到仓库。

请记住，工作目录下的每一个文件都不外乎这两种状态：已跟踪 或 未跟踪。
已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。
工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们， 而你尚未编辑过它们。
编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。
文件的状态变化周期图：
track跟踪，stage暂存，commit提交

2.2.1 检查当前文件状态

git status
# git status 命令的输出十分详细，但其用语有些繁琐。 Git 有一个选项可以帮你缩短状态命令的输出，这样可以以简洁的方式查看更改。 如果你使用 git status -s 命令或 git status --short 命令，你将得到一种格式更为紧凑的输出。

未跟踪文件：Untracked files
在之前的快照（提交）中没有这些文件，Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”。

2.2.2 跟踪新文件

git add +文件名/目录
#git add 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。
多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。
理解为 “精确地将内容添加到下一次提交commit中” 而不是“将一个文件添加到项目中”要更加合适。

已暂存状态：Changes to be committed

2.2.3 暂存已修改的文件

跟踪文件的内容发生了变化，但还没有放到暂存区(stage)：Changes not staged for commit

2.2.4 忽略文件

要养成一开始就为你的新仓库设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。

$ cat .gitignore
# 查看系统默认忽略了什么

2.2.5 查看已暂存和未暂存的修改

git status 命令的输出过于简略，
想知道具体修改了什么地方，可以用 git diff 命令

git diff
# 比较的是工作目录中当前文件和暂存区staged域快照之间的差异。 也就是修改之后还没有暂存起来的变化内容。
# git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。 

2.2.6 提交更新

每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了， 然后再运行提交命令 git commit。
git commit 会启动你选择的文本编辑器来输入提交说明(新增or删除的内容)。

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改过。
提交时记录的是放在暂存区域的快照。 任何还未暂存文件的仍然保持已修改状态，可以在下次提交时纳入版本管理。 每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。

2.2.7 跳过使用暂存区域

只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤， 这很方便，但是要小心，有时这个选项会将不需要的文件添加到提交中。

$ git commit -a -m 'added new benchmarks'

2.2.8 移除文件

1、要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。 可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。

#如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是 未暂存清单）看到：
$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

然后再运行 git rm 记录此次移除文件的操作：
$ git rm PROJECTS.md

如果要删除之前修改过 或已经放到暂存区的文件，则必须使用强制删除选项 -f（译注：即 force 的首字母）

2、另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。 换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。 为达到这一目的，使用 --cached 选项：

$ git rm --cached README git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。比如：

$ git rm log/*.log 注意到星号 * 之前的反斜杠 \， 因为 Git 有它自己的文件模式扩展匹配方式，所以我们不用 shell 来帮忙展开。 此命令删除 log/ 目录下扩展名为 .log 的所有文件。 类似的比如：

$ git rm *~ 该命令会删除所有名字以 ~ 结尾的文件。

2.2.9 移动文件

Git 并不显式跟踪文件移动操作。
要在 Git 中对文件改名，可以这么做：
$ git mv file_from file_to

$ git mv README.md README
$ git status

2.3 查看提交历史

git log 命令
用 “simplegit” 项目作为示例。 运行下面的命令获取该项目：

$ git clone https://github.com/schacon/simplegit-progit
当你在此项目中运行 git log 命令时，可以看到下面的输出：

$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sat Mar 15 16:40:33 2008 -0700

    removed unnecessary test

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sat Mar 15 10:31:28 2008 -0700

    first commit

不传入任何参数的默认情况下，git log 会按时间先后顺序列出所有的提交，最近的更新排在最上面。 正如你所看到的，这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。
git log 有许多选项可以帮助你搜寻你所要找的提交， -p，–patch(显示每次提交所引入的差异（按 补丁 的格式输出）)
限制显示的日志条目数量，例如使用 -2 选项来只显示最近的两次提交：git log -p -2

Table 2. 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 合用的简写。

2.3.1 限制输出长度

2.3.2 Tip

隐藏合并提交：log 加上 --no-merges 选项
按照你代码仓库的工作流程，记录中可能有为数不少的合并提交，它们所包含的信息通常并不多。

2.4 撤消操作

 --amend 选项的提交命令来重新提交：提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了
$ git commit --amend

提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

Note ：当你在修补最后的提交时，与其说是修复旧提交，倒不如说是完全用一个 新的提交 替换旧的提交， 理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。

修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史。

2.4.1 取消暂存的文件

例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交， 但是却意外地输入 git add * 暂存了它们两个。如何只取消暂存两个中的一个呢？ git status 命令提示了你：

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
#在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD ... 来取消暂存。

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD … 来取消暂存。 所以，我们可以这样来取消暂存 CONTRIBUTING.md 文件：

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

2.4.2 撤消对文件的修改

如果你并不想保留对 CONTRIBUTING.md 文件的修改怎么办？ 该如何方便地撤消修改——将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？ 幸运的是，git status 也告诉了应该如何做。 在最后一个例子中，未暂存区域是这样：

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

它非常清楚地告诉了如何撤消之前所做的修改。 让我们来按照提示执行：

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

2.4.3 Important

请务必记得 git checkout – 是一个危险的命令。 你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。 除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。

如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，我们将会在 Git 分支 介绍保存进度与分支，这通常是更好的做法。

记住，在 Git 中任何 已提交 的东西几乎总是可以恢复的。 甚至那些被删除的分支中的提交或使用 --amend 选项覆盖的提交也可以恢复 （阅读 数据恢复 了解数据恢复）。 然而，任何你未提交的东西丢失后很可能再也找不到了。

2.5 远程仓库的使用

管理远程仓库包括了解 如何添加远程仓库、移除无效的远程仓库、管理不同的远程分支并定义它们是否被跟踪等等。

2.5.1 Note

远程仓库可以在你的本地主机上 你完全可以在一个“远程”仓库上工作，而实际上它在你本地的主机上。 词语“远程”未必表示仓库在网络或互联网上的其它位置，而只是表示它在别处。 在这样的远程仓库上工作，仍然需要和其它远程仓库上一样的标准推送、拉取和抓取操作。

2.5.2 查看远程仓库

如果想查看你已经配置的远程仓库服务器，可以运行 git remote 命令。 它会列出你指定的每一个远程服务器的简写。 如果你已经克隆了自己的仓库，那么至少应该能看到 origin ——这是 Git 给你克隆的仓库服务器的默认名字：

$ git clone https://github.com/schacon/ticgit

$ cd ticgit
$ git remote
origin

# 也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL。
$ git remote -v
origin	https://github.com/schacon/ticgit (fetch)
origin	https://github.com/schacon/ticgit (push)

2.5.3 添加远程仓库

$ git remote
origin
#运行 git remote add 添加一个新的远程 Git 仓库，同时指定一个方便使用的简写：
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin	https://github.com/schacon/ticgit (fetch)
origin	https://github.com/schacon/ticgit (push)
pb	https://github.com/paulboone/ticgit (fetch)
pb	https://github.com/paulboone/ticgit (push)


# 现在你可以在命令行中使用字符串 pb 来代替整个 URL。
# 如果你想拉取 Paul 的仓库中有但你没有的信息，可以运行 git fetch pb
$ git fetch pb

可以用 git pull 命令来自动抓取后合并该远程分支到当前分支。
默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或其它名字的默认分支）。 运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。

2.5.4 推送到远程仓库

当你想分享你的项目时，必须将其推送到上游。 这个命令很简单：git push 。

2.5.5 远程仓库的重命名与移除

git remote rename 来修改一个远程仓库的简写名

$ git remote rename pb paul
$ git remote
origin
paul

如果因为一些原因想要移除一个远程仓库——你已经从服务器上搬走了或不再想使用某一个特定的镜像了， 又或者某一个贡献者不再贡献了——可以使用 git remote remove 或 git remote rm ：

$ git remote remove paul
$ git remote
origin

2.6 打标签

版本号

2.6.1 列出标签

$ git tag （可带上可选的 -l 选项 --list）
v1.0
v2.0

Note 按照通配符列出标签需要 -l 或 --list 选项 如果你只想要完整的标签列表，那么运行 git tag 就会默认假定你想要一个列表，它会直接给你列出来， 此时的 -l 或 --list 是可选的。

然而，如果你提供了一个匹配标签名的通配模式，那么 -l 或 --list 就是强制使用的。

2.6.2 创建标签

Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。
轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。
而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。 通常会建议创建附注标签，这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签， 或者因为某些原因不想要保存这些信息，那么也可以用轻量标签。

2.6.3 附注标签

创建：最简单的方式是当你在运行 tag 命令时指定 -a 选项

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4
-m 选项指定了一条将会存储在标签中的信息。 如果没有为附注标签指定一条信息，Git 会启动编辑器要求你输入信息。

通过使用 git show 命令可以看到标签信息和与之对应的提交信息：

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:19:12 2014 -0700
# 输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。
my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

2.6.4 轻量标签

另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
这时，如果在标签上运行 git show，你不会看到额外的标签信息。 命令只会显示出提交信息：

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

2.6.5 后期打标签

可以对过去的提交打标签。 假设提交历史是这样的：

2.6.6 共享标签

2.6.7 删除标签

要删除掉你本地仓库上的标签，可以使用命令 git tag -d 。
例如，可以使用以下命令删除一个轻量标签：

$ git tag -d v1.4-lw 

注意上述命令并不会从任何远程仓库中移除这个标签，你必须用 git push :refs/tags/ 来更新你的远程仓库：
第一种变体是 git push :refs/tags/ ：

$ git push origin :refs/tags/v1.4-lw To /git@github.com:schacon/simplegit.git
[deleted] v1.4-lw 
#上面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。

第二种更直观的删除远程标签的方式是：

$ git push origin --delete

2.6.8 检出标签

git checkout

2.7 Git 别名

如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。 这里有一些例子你可以试试：

$ git config --global alias.ci commit
这意味着，当要输入 git commit 时，只需要输入 git ci

教程来源