Git使用教程

浅浅的花香味﹌ 2022-06-08 03:06 216阅读 0赞

### 文章目录 ###

*   *  前言
     *  一、Git 基础
     *   *  1.1 版本控制系统
         *  1.2 安装 Git
         *  1.3 工作区和暂存区
         *  1.4 三个具有代表性的命令
     *  二、版本控制
     *   *  2.1 创建版本库
         *  2.2 查看仓库状态
         *  2.3 版本回退
         *  2.4 撤销修改
         *  2.5 删除文件
         *  2.6 命令小节
     *  三、远程仓库
     *   *  3.1 创建和设置远程仓库
         *  3.2 添加远程库
         *  3.3 从远程库克隆
         *  3.4 命令小节
     *  四、分支管理
     *   *  4.1 创建与合并分支
         *  4.2 解决冲突
         *  4.3 分支管理策略
         *  4.4 Bug 分支
         *  4.5 多人协作
         *  4.6 命令小节
     *  五、标签管理
     *   *  5.1 创建标签
         *  5.2 操作标签
         *  5.3 命令小节
     *  六、自定义 Git
     *   *  6.1 搭建 Git 服务器
         *   *  6.1.1 搭建环境
             *  6.1.2 管理公钥
         *  6.2 设置忽略文件

--------------------

## 前言 ##

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。本文为廖雪峰的Git教程的个人笔记，欢迎指正。

## 一、Git 基础 ##

### 1.1 版本控制系统 ###

版本控制系统系统分为**集中式**和**分布式**两种。

集中式是集中存放在中央服务器中，工作的时候，先用自己的电脑从中央服务器取得最新的版本，完工后，再把自己的工作推送到中央服务器。集中式版本控制工具有：CVS、SVN 等。

集中式的特点是需要联网才能工作，对网速的要求较高。如果中央服务器发生了宕机，所有人都没法工作。

![集中式][20170912171557531]

分布式版本控制系统没有“中央服务器”，每个人的电脑上都是一个完整的版本库，工作的时候不需要联网。需要彼此的文件，只需要相互推送。实际使用中，分布式版本控制控制系统通常也有一台充当“中央服务器”的电脑，但仅仅是用来方便“交换”大家的修改，没有它大家一样能正常工作，只是交换修改不方便。分布式版本控制工具有：`Git`、Mercurial、Bazaar 等。

分布式的特点是不需要联网就能工作。不依赖中央服务器，安全性高。

![分布式][20170912171610347]

### 1.2 安装 Git ###

测试是否正确安装了Git

![Git测试安装][Git]

如果像上图这样显示没有安装，通过相应包管理直接安装即可。我的电脑为`CentOs`，因此键入命令

yum install git

安装完成后，还需要最后一步设置，在命令行输入：

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

因为 Git 是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和 Email 地址。

注意：`git config` 命令的 `--global` 参数，用了这个参数，表示你这台机器上所有的 Git 仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

![自报家门][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgwMDA1MDUx]

### 1.3 工作区和暂存区 ###

Git和其他版本控制系统如SVN有一个不同之处就是有`暂存区`的概念。首先我们先了解以下概念的意义。

**工作区（Working Directory）**

就是你在电脑里能看到的目录，比如learngit文件夹就是一个工作区：

![工作区][20170912172000402]

**版本库（Repository）**

版本库可以理解为一个目录，在目录中的所有文件都可以被 Git 管理起来，每个文件的修改、删除，Git 都能跟踪，一边任何时刻都可以追踪历史，或者在将来进行还原。

工作区有一个隐藏目录 `.git`，这个不算工作区，而是 Git 的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为 `stage`（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支 `master`，以及指向master的一个指针叫 `HEAD`。

![版本库][20170912172033783]

我们把文件往Git版本库里添加的时候，是分两步执行的：

1.  `git add` 把文件添加进去，实际上就是把文件修改添加到暂存区；
2.  `git commit` 提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建 Git 版本库时，Git 自动为我们创建了唯一一个 master 分支，所以，现在，`git commit` 就是往 master分支上提交更改。

你可以简单理解为，**需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改**。

### 1.4 三个具有代表性的命令 ###

1.  添加到版本库：`git add`
2.  提交到版本库：`git commit`
3.  把本地版本库推送到远程版本库：`git push`

![三大命令][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTcyNjAxMTU3]

## 二、版本控制 ##

### 2.1 创建版本库 ###

选择合适路径，创建一个空目录，使用 `git init` 初始化 git 管理的目录

![创建版本库][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTc1NDI5OTMy]

然后我们添加文件到版本库：

1.  编辑文本文件 readme.txt
2.  添加到版本库：`git add`
3.  提交到版本库：`git commit`

> 注1：commit 命令使用 `-m` 参数可以添加本次提交的注释。这非常有用，在团队合作中能够让别人理解你本次提交的修改内容。  
> 注2：我们可以用 git add 添加多个文件到暂存区，然后使用 git commit 一次性提交。

![提交文件][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgwNjU2OTc0]

### 2.2 查看仓库状态 ###

**git status** 查看当前仓库状态。

修改 readme.txt 文件，使用 `git status` 查看仓库状态，下图说明 readme.txt 文件被修改，但还没有提交到仓库。

![查看仓库状态][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgxMjA5NzE5]

**git diff** 查看修改的内容

下图说明 readme.txt，添加了一行内容。

![查看修改][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgxODUzNjU3]

将 readme.txt 添加到暂存区并提交后，再次使用 `git status` 和 `git diff` 查看。

![查看修改2][2]

**git log** 查看仓库历史纪录

`git log` 命令显示从最近到最远的提交日志。

![查看历史纪录][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxMzMyNDQy]

### 2.3 版本回退 ###

**git reset** 回退到指定版本

`git reset` 具有三个参数，分别是 `soft`、`hard` 和 `mixed`。

`--soft` 参数告诉 Git 重置 HEAD 到另外一个 commit，但也到此为止。如果你指定 --soft 参数，Git将停止在那里而什么也不会根本变化。这意味着 index, working copy 都不会做任何变化，所有的在 original HEAD 和你重置到的那个 commit 之间的所有变更集仍然在stage(index)区域中。

![git reset --soft][]

`--hard` 参数将会将重置 HEAD 返回到另外一个 commit(取决于~12的参数），重置index以便反映HEAD的变化，并且重置 working copy 也使得其完全匹配起来。这是一个比较危险的动作，具有破坏性，数据因此可能会丢失！如果真是发生了数据丢失又希望找回来，那么只有使用 `git reflog` 命令了。

![git reset --hard][]

`--mixed` 是 reset 的默认参数，也就是当你不指定任何参数时的参数。它将重置 HEAD 到另外一个 commit,并且重置index 以便和 HEAD比配，但是也到此为止。working copy 不会被更改。所以所有从 original HEAD到你重置到的那个 commit 之间的所有变更仍然保存在 working copy中，被标示为已变更，但是并未staged的状态。

![git reset --mixed][]

Git 中，用 HEAD 表示当前版本，上一个版本就是HEAD^ ，上上个版本就是HEAD^^。  
撤销后再查看记录发现提交记录少了一个

![版本撤销][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxNTE5ODA2]

也可以指定回滚的版本号。版本号用 `git log` 查看 commit id 前7位。

如果我们忘记回退前的版本号，`git reflog` 命令记录了每一次的命令操作，包含了所有版本的版本号。

![查看操作记录][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxODUyMjIw]

### 2.4 撤销修改 ###

**git checkout - - file**

该命令会把文件在工作区的修改全部撤销，回到最近一次 `git commit` 或 `git add` 时的状态。

*  文件自修改后还没有被放到暂存区，撤销修改就回到和版本库一模一样的状态
 *  文件已经添加到了暂存区后。又做了修改，撤销修改就回到添加到暂存区后的状态。

注：`--`请不要丢掉，丢掉后就成为了创建分支的命令。

![撤销修改][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyMjAxNTgy]

**git reset HEAD file**

该命令会把暂存区的修改撤销掉，重新放回工作区中。

我们之前在回退版本时已经介绍了`git reset`命令，该命令既可以回退版本，也可以把工作区的某些文件替换为版本库中的文件。使用HEAD表示为最新的版本。

### 2.5 删除文件 ###

**git rm file**

如果使用 rm 删除了版本库中的文件 test.txt，然后用 `git status` 查看仓库状态。

![查看删除文件][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyNjIxMTk5]

如果确实要将test.txt文件从Git仓库删除，使用`git rm`，并commit。

![git中删除][git]  
![提交删除][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyODUxOTI1]

如果误删，使用 `git checkout -- file` 恢复到之前版本。

![误删文件][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyNDUxOTU5]

### 2.6 命令小节 ###

![版本控制命令小节][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcxMTI2MjAzMTEzNTEw]

## 三、远程仓库 ##

远程仓库即远程的Git服务器仓库，每个用户都能从这个服务器仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库中，也可以从服务器仓库中获取别人的提交。

### 3.1 创建和设置远程仓库 ###

我们可以使用自己的服务器创建一个Git仓库，也可以使用GitHub为我们提供的仓库。这里使用GitHub，首先注册[GitHub][]账号。

GitHub需要识别推送者的身份，防止别人冒充。Git支持SSH协议，因此GitHub只要知道了你的公钥，就可以确认推送者的身份。GitHub允许添加多个Key，确保用户可以在多台电脑上进行推送。

需要注意的是，GitHub只免费提供公开的Git库，因此你提交的内容所有人都可以查看，因此敏感信息尽量不要出现。如果不想让别人看到，可以选择GitHub付费服务或者自己搭建Git服务器。（2019年1月 Github 推出了私有仓库）

首先创建SSH Key密钥。一路回车使用默认值即可（如果没有特殊需求无需设置密码）：

> ssh-keygen -t rsa -C “user.email”

![创建密钥][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTk1MDEyMjEx]

然后可以在用户主目录里找到.ssh目录，里面有 `id_rsa` 和 `id_rsa.pub` 两个文件，这两个就是 SSH Key 的秘钥对，`id_rsa` 是私钥，不能泄露出去，`id_rsa.pub` 是公钥，可以放心地告诉任何人。

复制 `~/.ssh/id_rsa.pub` 内容。

![查看公钥][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTk1MDUxODIy]

第二步，登陆GitHub，打开`Settings` \-->`SSH And GPL Keys`–>`New SSH key`–> `Add SSH key`，将之前的内容粘贴上去即可。

![添加Key][Key]

### 3.2 添加远程库 ###

首先登陆自己的GitHub，创建一个新的仓库，这里我设置仓库名为Test。

![创建仓库][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAwMzUxOTk4]

GitHub告诉我们有以下几种选择：

*  从这个仓库克隆出新的仓库
 *  把一个已有的本地仓库与之关联
 *  从其他仓库导入代码。

根据提示，我们把本地仓库的内容推送到 GitHub 仓库。在本地仓库下，执行 GitHub 提示我们的命令即可。

![关联仓库][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAwNjQzNzQ1]

由于远程库是空的，我们第一次推送 master 分支时，加上了 `-u` 参数，Git不但会把本地的master分支内容推送的远程新的 master 分支，还会把本地的 master 分支和远程的 master 分支关联起来，在以后的推送或者拉取时就可以不使用 `-u` 参数。

我们发现上图中出现了 Warning，这是因为当你第一次使用 Git 的 clone 或者 push 命令连接 GitHub 时，由于我们使用 SSH 连接，而 SSH 连接在第一次验证 GitHub 服务器的 Key 时，需要你确认 GitHub 的 Key 的指纹信息是否真的来自 GitHub 的服务器，输入 yes 回车即可。

Git 会输出一个警告，告诉你已经把 GitHub 的 Key 添加到本机的一个信任列表里了，这个警告只会出现一次，后面的操作就不会有任何警告了。

### 3.3 从远程库克隆 ###

这里用我已经存在的 OJCrawler 项目为例，用命令 `git clone` 将该项目克隆到本地。

git clone git@github.com:jitwxs/OJCrawler.git

![克隆仓库到本地][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAxNjM1OTky]

### 3.4 命令小节 ###

![远程控制命令小节][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAyNTU1NzQ2]

## 四、分支管理 ##

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 Git 的时候，另一个你正在另一个平行宇宙里努力学习 SVN。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 Git 又学会了 SVN！

![分支漫画][20170912204359273]

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如 SVN 等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，得益于它的数据结构，使得无论创建、切换和删除分支，Git 在很短时间就能完成。

### 4.1 创建与合并分支 ###

Git 将每次提交的内容串成一条时间线，这条时间线就是一个分支。在默认情况下只有一个分支，这个分支叫主分支，即 master 分支。HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master 分支是一条线，Git 用 master 指向最新的提交，再用 HEAD 指向 master，就能确定当前分支，以及当前分支的提交点：

![20170912205225773][]

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

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

![20170912205300693][]

由这个数据结构我们知道，Git 创建一个分支很快，因为除了增加一个 dev 指针，改改 HEAD 的指向，工作区的文件都没有任何变化！

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

![20170912205342023][]

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

![20170912205415023][]

合并完分支后，甚至可以删除 dev 分支。删除 dev 分支就是把 dev 指针给删掉，删掉后，我们就剩下了一条master 分支：

![20170912205428759][]

说了这么多理论，下面开始实际操作。

首先，我们创建 dev 分支，然后切换到 dev 分支：

git checkout -b dev

`git checkout` 命令加上 `-b` 参数表示创建并切换，相当于以下两条命令：

git branch dev
    git checkout dev

然后，用 `git branch` 命令查看分支，当前活跃分支前会添加 `*` 号：

![查看分支][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEwMTIyMjQw]

下面我们为 readme.txt 文件添加一行，并提交 dev 分支。

![在dev分支修改内容][dev]

切换回 master 分支后，再查看一个 readme.txt 文件，刚才添加的内容不见了！

![切换回master][master]

因为那个提交是在 dev 分支上，而 master 分支此刻的提交点并没有变。

![20170912210710293][]

现在，我们把 dev 分支的工作成果合并到 master 分支上，`git merge` 命令用于合并指定分支到当前分支。

合并后，再查看 readme.txt 的内容，就可以看到，和 dev 分支的最新提交是完全一样的。

![合并dev分支][dev 1]

注意到上面的 Fast-forward 信息，Git 告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除 dev 分支了 使用 `git branch -d 分支名`。

删除后，查看 branch，就只剩下 master 分支了：

![删除dev分支][dev 2]

因为创建、合并和删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

### 4.2 解决冲突 ###

合并分支并非总是这么一帆风顺，有可能遇上冲突问题。准备新的 feature1 分支，来模拟冲突问题。

![创建feature1分支][feature1]

修改 readme.txt 最后一行，改为：

> this changed by feature1 branch…

在 feature1 分支上提交：

![提交feature1][feature1 1]

切换到 master 分支：

![切换master][master 1]

Git 还会自动提示我们当前 master 分支比远程的 master 分支要超前 1 个提交。

在 master 分支上把 readme.txt 文件的最后一行改为：

> this changed by master branch…

提交：

![提交master][master 2]

现在，master 分支和 feature1 分支各自都分别有新的提交，变成了这样：

![20170912212658873][]

这种情况下，Git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

![尝试合并冲突][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEyNzQwNzky]

果然冲突了！Git 告诉我们，readme.txt 文件存在冲突，必须手动解决冲突后再提交。

`git status` 也可以告诉我们冲突的文件：

![git status冲突][git status]

我们可以直接查看 readme.txt 的内容：

![查看冲突内容][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEyOTEwODIz]

Git用`<<<<<<<`，`=======`，`>>>>>>>`标记出不同分支的内容，我们将最后一行修改如下后保存：

> this changed by master and dev branch…

再提交：

![查看合并][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEzMDEzODc0]

现在，master 分支和 feature1 分支变成了下图所示：

![20170912213042282][]

用带参数的 `git log` 也可以看到分支的合并情况：

git log --graph --pretty=oneline --abbrev-commit

![git log冲突][git log]

最后，删除 feature1 分支：

![删除feature1][feature1 2]

### 4.3 分支管理策略 ###

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

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

下面我们实战一下 non-fast-forward 方式的 merge。

首先，仍然创建并切换 dev 分支：

![创建dev分支][dev 3]

修改 readme.txt 文件，并提交一个新的 commit：

![提交dev分支][dev 4]

现在，我们切换回 master：

![切换到master][master 3]

准备合并 dev 分支，请注意 `--no-ff` 参数，表示禁用 Fast forward。因为本次合并要创建一个新的 commit，所以加上`-m` 参数，把 commit 描述写进去。

![noff合并分支][noff]

合并后，我们用 git log 看看分支历史：

![git log历史][git log 1]

可以看到，不使用 Fast forward 模式，merge 后就像这样：

![20170912215835059][]

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

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

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

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

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

![分支策略][20170912215858481]

### 4.4 Bug 分支 ###

当你接到一个修复 bug 的任务时，很自然地，你想创建一个分支来修复它。但是等等，当前分支上进行的工作还没有提交。并不是你不想提交，而是工作只进行到一半，还没法提交。如下图，demo.c 文件还没有完成，无法提交。

![无法提交演示][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjIyMDU0NTQ5]

但是，你必须紧急修复该 bug，怎么办？幸好，Git还提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。

![stash][]

现在，用 `git status` 查看工作区，就是干净的（除非有没有被 Git 管理的文件），因此可以放心地创建分支来修复 bug。

![查看隐藏后status][status]

首先确定要在哪个分支上修复 bug，假定需要在 master 分支上修复，就从 master 创建临时分支：

![创建issue分支][issue]

现在模拟修复 bug，随便修改 readme.txt 内容，然后提交：

![提交issue分支][issue 1]

修复完成后，切换到 master 分支，并完成合并，最后删除 issue 分支：

![删除issue][issue 2]

修复完了 Bug，是时候接着回到 dev 分支干活了！

![返回dev][dev 5]

工作区是干净的，刚才的工作现场存到哪去了？用 `git stash list` 命令看看：

![查看stash][stash 1]

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下，有两个办法：

*  用 `git stash apply` 恢复，但是恢复后，stash 内容并不删除，你需要用 `git stash drop` 来删除。
 *  用 `git stash pop`，恢复的同时把 stash 内容也删了。

这里假设我们不需要保留 stash 的内容了，使用 `git stash pop` 命令。再用 `git stash list` 查看，就看不到任何 stash 内容了：

![stash pop][]

当然了，你可以多次stash，恢复的时候，先用`git stash list`查看，然后恢复指定的stash，用命令：

git stash apply stash@{ 0}

### 4.5 多人协作 ###

你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是 origin。

用 `git remote` 查看远程库的信息,或者，用 `git remote -v` 显示更详细的信息：

![git remote][]

上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限，就看不到 push 的地址。

多人协作时，大家都会往 master 和 dev 分支上推送各自的修改。

当你的小伙伴从远程库 clone 时，默认情况下，你的小伙伴只能看到本地的 master 分支。

现在，你的小伙伴要在 dev 分支上开发，就必须创建远程 origin 的 dev 分支到本地，于是他用 `git checkout -b dev origin/dev` 创建本地 dev 分支：

现在，他就可以在dev上继续修改，然后，时不时地把 dev 分支 push 到远程。

碰巧你也对同样的文件作了修改，并试图推送就会出错失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，先用git pull把最新的提交从 `origin/dev` 克隆下来，然后，在本地合并，解决冲突，再推送：

以上就是多人协作的工作模式，下面来总结一下：

*  首先，可以试图用 `git push origin branch-name` 推送自己的修改；
 *  如果推送失败，则因为远程分支比你的本地更新，需要先用`git pull`试图合并；
 *  如果合并有冲突，则解决冲突，并在本地提交；
 *  没有冲突或者解决掉冲突后，再用 `git push origin branch-name` 推送就能成功！
 *  如果 `git pull` 提示 “no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令 `git branch --set-upstream branch-name origin/branch-name`。

### 4.6 命令小节 ###

![分支命令][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjI0NjA3MTA3]

## 五、标签管理 ##

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（与分支很像但是分支可以移动，标签不能移动）。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e…”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

### 5.1 创建标签 ###

在Git中打标签非常简单，首先，切换到需要打标签的分支上，然后，敲命令 `git tag <name>` 就可以打一个新标签：

![打标签][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjI1NzQxMDQ5]

可以用命令 `git tag` 查看所有标签：

![查看标签][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyMzU1Mzg2]

默认标签是打在最新提交的 commit 上的。如果想要给历史 commit 打标签，可以找到历史提交的 commit id，然后打上就可以了：

![查看git log][git log 2]

比方说要对 add merge 这次提交打标签，它对应的 commit id 是 3728b64，敲入命令 `git tag v0.1 6224937`：

再用命令 `git tag` 查看标签：

![查看标签2][2 1]

注意，标签不是按时间顺序列出，而是按字母排序的。可以用 `git show <tagname>` 查看标签信息：

![查看标签具体][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyNjEzNDIy]

可以看到，v0.1 确实打在 add merge 这次提交上。

还可以创建带有说明的标签，用 `-a` 指定标签名，`-m` 指定说明文字，例如：

git tag -a v0.1 -m "version 0.1 released" 3628164

还可以通过 `-s` 用私钥签名一个标签：

$ git tag -s v0.2 -m "signed version 0.2 released" fec145a

签名采用 PGP 签名，因此，必须首先安装 gpg（GnuPG）,用 PGP 签名的标签是不可伪造的，因为可以验证 PGP 签名。

### 5.2 操作标签 ###

如果标签打错了，也可以删除：

git tag -d v0.1

![删除标签][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMwNDQ3ODky]

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送某个标签到远程，使用命令 `git push origin <tagname>`，或者，使用 `git push origin --tags` 一次性推送全部尚未推送到远程的本地标签。

![推送标签][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMwNTE4OTc5]

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

git tag -d v0.1

然后，从远程删除。删除命令也是 push，但是格式如下：

git push origin :refs/tags/v0.1

要看看是否真的从远程库删除了标签，可以登陆 GitHub 查看。

### 5.3 命令小节 ###

![标签命令][aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyNjQ3NTAz]

## 六、自定义 Git ##

### 6.1 搭建 Git 服务器 ###

#### 6.1.1 搭建环境 ####

GitHub 就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给 GitHub 交保护费，那就只能自己搭建一台 Git 服务器作为私有仓库使用。

搭建 Git 服务器需要准备一台运行 Linux 的机器或服务器。

假设你已经有 sudo 权限的用户账号，下面，正式开始安装。

第一步，安装 git

第二步，创建一个 git 用户，用来运行 git 服务：

sudo adduser git

第三步，创建证书登录：

收集所有需要登录的用户的公钥，就是他们自己的 `id_rsa.pub` 文件，把所有公钥导入到 `/home/git/.ssh/authorized_keys` 文件里，一行一个。

第四步，初始化 Git 仓库：

先选定一个目录作为 Git 仓库，假定是 /srv/sample.git，在 /srv 目录下输入命令：

sudo git init --bare sample.git

Git 就会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以.git结尾。然后，把owner改为git：

sudo chown -R git:git sample.git

第五步，禁用 shell 登录：

出于安全考虑，第二步创建的 git 用户不允许登录shell，这可以通过编辑 `/etc/passwd` 文件完成。找到类似下面的一行：

git:x:1001:1001:,,,:/home/git:/bin/bash

改为：

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

这样，git 用户可以正常通过 ssh 使用 git，但无法登录 shell，因为我们为 git 用户指定的 git-shell 每次一登录就自动退出。

第六步，克隆远程仓库：

现在，可以通过 git clone 命令克隆远程仓库了，在各自的电脑上运行：

git clone git@server:/srv/sample.git

剩下的推送就简单了。

#### 6.1.2 管理公钥 ####

如果团队很小，把每个人的公钥收集起来放到服务器的/home/git/.ssh/authorized\_keys文件里就是可行的。如果团队有几百号人，可以用Gitosis来管理公钥。

### 6.2 设置忽略文件 ###

有些时候，你必须把某些文件放到 Git 工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次 `git status` 都会显示 `Untracked files ...`。

好在 Git 考虑到了大家的感受，这个问题解决起来也很简单，在 Git 工作区的根目录下创建一个特殊的 `.gitignore` 文件，然后把要忽略的文件名填进去，Git 就会自动忽略这些文件。

GitHub 已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：[https://github.com/github/gitignore][https_github.com_github_gitignore] 。

忽略文件的原则是：

*  忽略操作系统自动生成的文件，比如缩略图等；
 *  忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
 *  忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

举个例子：

假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：

# Windows:
    Thumbs.db
    ehthumbs.db
    Desktop.ini

然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：

# Python:
    *.py[cod]
    *.so
    *.egg
    *.egg-info
    dist
    build

加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：

# Windows:
    Thumbs.db
    ehthumbs.db
    Desktop.ini
    
    # Python:
    *.py[cod]
    *.so
    *.egg
    *.egg-info
    dist
    build
    
    # My configurations:
    db.ini
    deploy_key_rsa

最后一步就是把 `.gitignore` 也提交到 Git，就完成了！当然检验 .gitignore 的标准是 `git status` 命令是不是说 `working directory clean`。

有些时候，你想添加一个文件到 Git，但发现添加不了，原因是这个文件被 .gitignore 忽略了：

$ git add App.class
    The following paths are ignored by one of your .gitignore files:
    App.class
    Use -f if you really want to add them.

如果你确实想添加该文件，可以用-f强制添加到Git：

$ git add -f App.class

或者你发现，可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，可以用 `git check-ignore` 命令检查：

$ git check-ignore -v App.class
    .gitignore:3:*.class    App.class

Git 会告诉我们，.gitignore 的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

[20170912171557531]: /images/20220608/8c9a7fd5ec1f41868f203bfc4002e91a.png
[20170912171610347]: /images/20220608/107d535c678c41138dcbf3e176d9d5d1.png
[Git]: /images/20220608/bacc98a5ec5e4b868a2b410842f8e044.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgwMDA1MDUx]: /images/20220608/11cd5cb2705f45708bad92aea8fc4977.png
[20170912172000402]: /images/20220608/985052f8858e440f9ee6245e83dbd861.png
[20170912172033783]: /images/20220608/8ebff12589bb4aaaae918ac7c135d2f1.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTcyNjAxMTU3]: /images/20220608/1ddf2a72e7084ef891db0c5ff18c3c16.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTc1NDI5OTMy]: /images/20220608/10976b3a3602450cb89b0d62e7970eb8.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgwNjU2OTc0]: /images/20220608/14deadf455aa4c619adb6d5cd5351c0f.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgxMjA5NzE5]: /images/20220608/caa8f756ca3c4ed2b0caf3ab57f48df3.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTgxODUzNjU3]: /images/20220608/b12f0232f68e4850812190ff720ca7c1.png
[2]: /images/20220608/4be7182932604698b59cd6a3654ab201.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxMzMyNDQy]: /images/20220608/72ac921c298846108ecf52092592b08a.png
[git reset --soft]: /images/20220608/ac5f4fc13f80446b95f006af7a5c23d0.png
[git reset --hard]: /images/20220608/44c42053a2fd405aabec7f872787848f.png
[git reset --mixed]: /images/20220608/c566615b52ef4f73849fbf5196241b86.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxNTE5ODA2]: /images/20220608/a4046c3dd1844d5483af7b61340180c9.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkxODUyMjIw]: /images/20220608/8260365807604b6ebcdab6f04719c739.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyMjAxNTgy]: /images/20220608/b6dd66b103a7440298eaaaa129ff92c0.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyNjIxMTk5]: /images/20220608/08d3d29e181640a48cfcea9678ee2507.png
[git]: /images/20220608/18a8c452ef5b459f9a02a1c2bcba6a24.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyODUxOTI1]: /images/20220608/3ec2f75740744a559a81db49108b0609.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTkyNDUxOTU5]: /images/20220608/b3cfcb6bd26c46a5a430e8ce84cadeff.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcxMTI2MjAzMTEzNTEw]: /images/20220608/63ff14751d8d4b8786f05a8fad7fd136.png
[GitHub]: https://github.com
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTk1MDEyMjEx]: /images/20220608/a8bc1bd58b0e4335ab3a7b04810e66fa.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMTk1MDUxODIy]: /images/20220608/47b5e1b8b081458b93d80fcac03bc80b.png
[Key]: /images/20220608/910ec1aaf701407eb2813610143c5328.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAwMzUxOTk4]: /images/20220608/2e393d4e08094f47b36bb7953beae314.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAwNjQzNzQ1]: /images/20220608/b0a8cb831b734e87be4554f98286c078.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAxNjM1OTky]: /images/20220608/010c0091ea7844f3a725893f4e09e45d.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjAyNTU1NzQ2]: /images/20220608/a55f289db1b24448b6cfdb2c686ee84c.png
[20170912204359273]: /images/20220608/120073aabbba4f5cb932d093185cf63a.png
[20170912205225773]: /images/20220608/f21121bb11064d2fb242336fbe7b1e7e.png
[20170912205300693]: /images/20220608/69d5832d626c48969ff3f254ff8b9117.png
[20170912205342023]: /images/20220608/2649d40c0eb94d71b75d505b4f3cf540.png
[20170912205415023]: /images/20220608/3f1ebfcf42464f6d84d8f38785e52935.png
[20170912205428759]: /images/20220608/74474cf48d4b434cb250ba35625b76e4.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEwMTIyMjQw]: /images/20220608/f5e0cdb13a1c4e67a7d23a4623aa11ac.png
[dev]: /images/20220608/e48ce52645f648c194da641c4d6ba10b.png
[master]: /images/20220608/0fdb0657196e4b0fb1dd8a6a978a9d5c.png
[20170912210710293]: /images/20220608/f54975db138642598661e9bd5054197b.png
[dev 1]: /images/20220608/8e353a2430634817963d2d2b9ca259cf.png
[dev 2]: /images/20220608/aab59b0b58bd4cd6a0d90e2526541943.png
[feature1]: /images/20220608/85b931127a13462f833389f8fab423e5.png
[feature1 1]: /images/20220608/d033d44fbe0443c9abe9677b1ac4626c.png
[master 1]: /images/20220608/76cb2827afca41689fece72d5105e4a0.png
[master 2]: /images/20220608/56cad5581faa4ae08ebaf31313a479a8.png
[20170912212658873]: /images/20220608/af81eafc18f8467482afb33f00ff299e.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEyNzQwNzky]: /images/20220608/47af292bb335492b911eb1591cb24491.png
[git status]: /images/20220608/2721d8b73a30405b91c38b6d60d3de60.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEyOTEwODIz]: /images/20220608/9dbd6414b66146cb9d4c35bca0c979b7.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjEzMDEzODc0]: /images/20220608/58422ede0cd94ed6898a93d904eb58ce.png
[20170912213042282]: /images/20220608/5ea055f0bfa64bc3b1486221d4a5c5ce.png
[git log]: /images/20220608/3de7162f34ff4759be947e1fe71181e5.png
[feature1 2]: /images/20220608/5a630e0b4ebe4d93973d6a844b4764a3.png
[dev 3]: /images/20220608/f9a5911a2b27448db32927ed039084b8.png
[dev 4]: /images/20220608/a0f9eb4f33664fd4b81e22bfeaee7973.png
[master 3]: /images/20220608/ff08618459714f51b895b545343b9c96.png
[noff]: /images/20220608/0abc75d98dfc4fb584a2668ba07c0df6.png
[git log 1]: /images/20220608/9a216dd0d73a422ea449191ca2790142.png
[20170912215835059]: /images/20220608/1e848237a0554db2a2427323b1ecda3d.png
[20170912215858481]: /images/20220608/8bb18ec33a4e474aa95027a79c3579e8.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjIyMDU0NTQ5]: /images/20220608/5177bf03970f4a78b4714612f03c4b20.png
[stash]: /images/20220608/58bc227ab6454c6b930bbc229c570201.png
[status]: /images/20220608/bdc1db3abe4142458efaafce6f1a1253.png
[issue]: /images/20220608/5bc51f8930534142b889b7a48dd4b6ff.png
[issue 1]: /images/20220608/c3e95a8bf62b4bb99851d28746d7d253.png
[issue 2]: /images/20220608/e19a754250f04b8090d710512c5d4158.png
[dev 5]: /images/20220608/ad8e0056c2e0465ea2d4c9c99ee5d963.png
[stash 1]: /images/20220608/e004366e74864af4803eaa756192158e.png
[stash pop]: /images/20220608/addf92e041ca439292a17f31df2965fd.png
[git remote]: /images/20220608/3e4e6339aa55427697af985460e1257e.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjI0NjA3MTA3]: /images/20220608/135cb6382692480ab65dc3808173de96.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjI1NzQxMDQ5]: /images/20220608/86c1886f157a4b849fd91530e518e637.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyMzU1Mzg2]: /images/20220608/e987f4d7d53b4711ba06ac014c822e88.png
[git log 2]: /images/20220608/edee451eeafd4c08a696916deb7e983e.png
[2 1]: /images/20220608/38b53c5be56343058fb36c6fdc78f9be.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyNjEzNDIy]: /images/20220608/8adc6c16b84849388dc7328d2ab5df62.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMwNDQ3ODky]: /images/20220608/4a23c9d21c154a1fbf95180022d5ad88.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMwNTE4OTc5]: /images/20220608/154a9f2052f14673b540881beffef168.png
[aHR0cDovL2ltZy1ibG9nLmNzZG4ubmV0LzIwMTcwOTEyMjMyNjQ3NTAz]: /images/20220608/ca2ad0deadcb414290bbcb17c006f4ef.png
[https_github.com_github_gitignore]: https://github.com/github/gitignore