【Git】简单使用

阳光穿透心脏的1/2处 2022-05-10 03:06 231阅读 0赞

如需转载请注明出处。  
win10 64位

# 1、预备知识 #

**一个人**： **Linus Torvalds**（全名：Linus Benedict Torvalds，译作 林纳斯·本纳第克特·托瓦兹）， **Linux内核的发明者**，现受聘于 **开放源代码开放实验室（OSDL）**，1969-12-28生于芬兰-赫尔辛基市，毕业于赫尔辛基大学。一个牛逼的低调人物。《时代》周刊20世纪100位最重要人物第15位（比尔盖茨才第17位哦）。21岁时完成Linux第一个内核雏形。 就是下方这位老帅哥，脱发不严重：

![在这里插入图片描述][70]  
**一个概念**：**版本控制系统（Version Control System，VCS）**，版本控制，是对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。其最主要的功能是 **追踪文件的变更**。

常用的CVS、SVN（开源的），ClearCase（IBM，收费的）、VSS（微软） ，都是**集中式**版本控制系统；

**一个工具**：**Git**，是**分布式**版本控制系统（一个工具），还有类似Git的Mercurial和Bazaar，本人没用过。大名鼎鼎的Git，由声名远扬的**Linus Torvalds**开发。源于2005年 **开发Linux Kernel的免费使用BitKeeper（BK，一个商业版本控制系统）权限被取消，促使Linus Torvalds开发出自个的项目版本管理工具**。听说从无到有，花了10天。

**Git优点：**  
**① 版本库本地化，支持离线提交（不像集中式VCS联网才能工作），相对独立不影响协同开发（强调个体，适合分布式开发）。**

每个开发者都拥有自己的版本控制库，可在自己的版本库上任意的执行提交代码、创建分支等行为。例如，开发者认为自己提交的代码有问题，因为版本库是自己的，可进行回滚历史、反复提交、归并分支，而并不会影响到其他开发者。

**② 更少的“仓库污染”。**

**Git** 对于每个工程只会产生一个`.git`目录，这个工程所有的版本控制信息都在这个目录中，不会像SVN那样在每个目录下都产生`.svn`目录。

**③ 把内容按元数据方式存储，完整克隆版本库。**

所有版本信息位于`.git`目录中，它是处于我们机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签、分支、版本记录等。

**④ 支持快速切换分支方便合并，比较合并性能好。**

在同一目录下即可切换不同的分支，方便合并，且合并文件速度比SVN快。

**⑤ 分布式版本库，无单点故障，内容完整性好。**

内容存储使用的是`SHA-1`哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

Git缺点：  
学习周期长些；不符合常规思维？；代码保密性稍差，一旦开发者把整个库clone下来就可完全公开所有代码和版本信息，即安全性低（当然适合于开源嘛）。

PS：**[GitHub][]**，一个面向开源及私有软件项目的远程**托管平台（即开源代码库、版本控制系统）**，因为只支持**Git**作为唯一的版本库格式进行托管，故名GitHub。（类似的还有GitLab，BitBucket，GitCafe。国内有[码云][Link 1]、[CODING][]（码市）、[阿里云 Code][Code]、[百度效率云][Link 2]、[华为CodeHub][CodeHub]）

2008年4月10日正式上线；2018年6月4日被微软75亿美金收购。它托管了海量git库，各种开源代码。

# 2、实操 #

## 2.1 Git下载安装 ##

[官方下载地址][Link 3]，目前最新版本`2.19.0`（2018-09-10）。

安装完成后，打开**Git Bash**（它是一个终端仿真器（Terminal Emulator）），在命令行窗口如下命令进行设置：

Administrator@Cchen-PC MINGW64 /
    $ git config --global user.name "Your Name"
    
    Administrator@Cchen-PC MINGW64 /
    $ git config --global user.email "email@example.com"

上述`git config`命令中的`--global`参数，表示该电脑上所有Git仓库都将使用这项配置；也可以对某个仓库指定不同的用户名和Email。

## 2.2 创建版本库（repository） ##

**repository**，译作 版本库（或仓库），可理解成一个目录，该目录里所有文件都可以被**Git**管理起来，里头每个文件的修改、删除，**Git**都能跟踪，以便任何时候都可以追踪历史，或在将来某个时刻“还原”。

如**D盘下`testGit`文件夹**是项目所在之处。

### 2.2.1 初始化Git仓库 ###

Administrator@Cchen-PC MINGW64 /
    $ cd D:\testGit
    
    Administrator@Cchen-PC MINGW64 /d/testGit
    $ git init
    Initialized empty Git repository in D:/testGit/.git/

`git init`命令作用是将项目所在目录变成**Git**可管理的仓库，自动新增一个`.git`目录，它是用于跟踪管理版本库。将包含如下文件夹和文件：  
![在这里插入图片描述][70 1]

### 2.2.2 添加项目文件到版本库 ###

1、`git add <文件名>`命令将项目文件添加到仓库：可反复多次使用，也可添加多个文件（以空格隔开）

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add readme.txt

**注：**  
①例中D:testGit/`readme.txt` 是随意编写一个文件。  
②所有版本控制系统，只能跟踪文本文件的改动，如html、各种程序代码、txt文件，且文本编码建议使用标准的UTF-8；而无法跟踪二进制文件，如图片、视频、word文档等，但可跟踪文件大小变动。  
③`git add .` 提交新文件（new）、被修改文件（modified），不包括被删除文件（deleted）；  
`git add -u` 提交被修改文件（modified）、被删除文件（deleted），不包括新文件（new）；  
`git add -A` 提交所有变化。

2、将文件提交到仓库：`git commit -m "备注信息"`

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "my first git commit:readme.txt"
    [master (root-commit) 9679b2f] my first git commit:readme.txt
     1 file changed, 1 insertion(+)
     create mode 100644 readme.txt

`-m`命令后是此次提交的说明，可输入有意义的内容，以便从历史记录找到改动记录。  
`git commit`命令执行成功后会打印消息：`1 file changed` 一个文件被改动；`1 insertion(+)` 插入了两行内容。

## 2.3 本地仓库Git管理 ##

### 2.3.1 查看仓库状态和被修改内容 ###

随意修改一下`readme.txt`文件。  
查看仓库当前状态信息：`git status`

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git status
    On branch master
    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:   readme.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")

`Changes not staged for commit` 译作 `未提交的更改 提交`  
`no changes added to commit` 译作 `没有更改添加到提交中`  
其中，`modified: readme.txt` 表示被修改的文件名。

查看仓库被修改的具体内容：`git diff <被修改文件>`

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git diff readme.txt
    diff --git a/readme.txt b/readme.txt
    index 60a3fa0..13e615b 100644
    --- a/readme.txt
    +++ b/readme.txt
    @@ -1 +1,2 @@
    -<U+FEFF>我的学习Git之路！
    \ No newline at end of file
    +<U+FEFF>我的学习Git之路！
    +我现在修改了。
    \ No newline at end of file

### 2.3.2 版本回退 ###

1、显示提交日志（历史）：`git log`命令

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git log
    commit a0ee5d135cff50f4c2d077a6754ad93ba4cf2bed
    Author: Yourname <Email address>
    Date:   Tue Sep 25 22:25:38 2018 +0800
    
        Third changed.
    
    commit 71d82e993205194bb216cc565a7444b900bd6a96
    Author: Yourname <Email address>
    Date:   Tue Sep 25 21:33:31 2018 +0800
    
        second commit
    
    commit 9679b2ff35572ca3b31bbf9bccf5e08e738451b5
    Author: Yourname <Email address>
    Date:   Tue Sep 25 20:57:36 2018 +0800
    
        my first git commit:readme.txt

`git log`命令将显示从时间轴上最近到最远的提交日志。其中`commit 71d82e99...`是`commit id`（版本号），`id`是由SHA1计算出的一个十六进制表示的数字。

`git log`命令加上参数`--pretty=oneline`将简化打印信息：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git log --pretty=oneline
    a0ee5d135cff50f4c2d077a6754ad93ba4cf2bed Third changed.
    71d82e993205194bb216cc565a7444b900bd6a96 second commit
    9679b2ff35572ca3b31bbf9bccf5e08e738451b5 my first git commit:readme.txt

2、版本回退：`git reset`命令，加上`--hard`参数，这个操作比较危险。  
在**Git**中：

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>HEAD</td> 
   <td>当前版本</td> 
  </tr> 
  <tr> 
   <td>HEAD^</td> 
   <td>上一个版本</td> 
  </tr> 
  <tr> 
   <td>HEAD^^</td> 
   <td>上上一个版本</td> 
  </tr> 
  <tr> 
   <td>HEAD~n</td> 
   <td>上n个版本</td> 
  </tr> 
 </tbody> 
</table>

例如：回退到上一个版本

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git reset --hard HEAD^
    HEAD is now at 71d82e9 second commit

3、查看当前版本的内容：`cat <文件名>`

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ cat readme.txt
    我的学习Git之路！
    我现在修改了。

根据`commit id`还可在上述例中已回退的版本回到“未来”的某个版本，如例中第三个版本：其中`commit id`不必全部输入（通常是前6位即可），输入前几位就OK。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git reset --hard a0ee5d135cff50f4c2d077a6754ad93ba4cf2bed
    HEAD is now at a0ee5d1 Third changed.
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ cat readme.txt
    我的学习Git之路！
    我现在修改了。
    我的第3次修改！

4、查看命令历史：`git reflog`命令，可用于确定回到未来的某个版本

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git reflog
    a0ee5d1 HEAD@{0}: reset: moving to a0ee5d135cff50f4c2d077a6754ad93ba4cf2bed
    71d82e9 HEAD@{1}: reset: moving to HEAD^
    a0ee5d1 HEAD@{2}: commit: Third changed.
    71d82e9 HEAD@{3}: commit: second commit
    9679b2f HEAD@{4}: commit (initial): my first git commit:readme.txt

### 2.3.3 工作区、暂存区、本地仓库 ###

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>工作区</td> 
   <td>代码编写、修改所在的目录，如我的例中<code>D:/testGit</code></td> 
  </tr> 
  <tr> 
   <td>暂存区</td> 
   <td><code>git add</code>命令将本地修改添加到暂存区（即<b>stage</b>或<b>index</b>）</td> 
  </tr> 
  <tr> 
   <td>本地仓库</td> 
   <td><code>git commit</code>命令将暂存区中的内容提交到本地仓库（也即 当前分支）</td> 
  </tr> 
 </tbody> 
</table>

在执行`git init`命令 初始化**Git**版本库（即创建**Git**版本库）时，**Git**将自动创建唯一一个`master`分支。`git commit`命令就是向`master`分支上提交更改。

例：再次修改（第4次）`readme.txt`文件；在工作区新增`LICENSE`文件（内容随意）

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ touch LICENSE # 新建LICENSE文件
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ vi LICENSE # 编辑LICENSE文件

查看此时仓库状态：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git status
    On branch master
    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:   readme.txt
    
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
    
            LICENSE
    
    no changes added to commit (use "git add" and/or "git commit -a")

上述打印告知：`readme.txt`被修改；`LICENSE`文件的状态是`Untracked`，译作 无足迹。即没被`git add`到仓库过。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add LICENSE
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
    
            new file:   LICENSE
            modified:   readme.txt
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "Fourth change for readme.txt and add LICENSE."
    [master 089ee82] Fourth change for readme.txt and add LICENSE.
    warning: LF will be replaced by CRLF in LICENSE.
    The file will have its original line endings in your working directory.
     2 files changed, 3 insertions(+), 1 deletion(-)
     create mode 100644 LICENSE

![在这里插入图片描述][70 2]

### 2.3.4 管理和撤销修改、删除文件 ###

1、管理修改

根据上一小节**流程图**可知：**Git****跟踪并管理**的是实质是修改，而非文件。即每一次的修改（如新增文件、新增/删除一行、更改内容）都得`git add`到暂存区，并`git commit`。

也就是说 如果没有把某次修改`git add`到暂存区，那么在执行`git commit`时将不会跟踪到这次修改的。

也换句话说，`git commit`只对暂存区负责。

2、撤销修改

现在，对D:/testGit/`readme.txt`进行一次修改（如新增一行）。

在修改完成后，如果反悔了不想要这次修改，有两种方案：  
方案1：在`readme.txt`删掉新增的那行；不过执行`git status`能看到文件被修改过。  
方案2：`git check -- readme.txt`命令执行撤销修改；

根据上一小节的流程图可知，可应用在如下**场景**：  
场景①：**工作区**修改了内容，想放弃工作区的修改时，运用`git checkout -- filename`命令；  
场景②：**工作区**修改了内容，而且还`git add`到了暂存区，想放弃修改，分两步：1）`git reset HEAD filename`命令回到①；2）按场景①操作。  
场景③：（没有推送到远程库）想放弃撤销本次提交，运用**版本回退**命令 `git reset`。

3、删除文件

删除也是一个修改操作。  
例：在工作区新增一个文件`abc.txt`；并提交到Git仓库。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add abc.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "add abc.txt"
    [master 7533102] add abc.txt
     1 file changed, 1 insertion(+)
     create mode 100644 abc.txt

场景：要删除`abc.txt`文件。  
方案1：直接在目录中手动删除`abc.txt`；  
方案2：`rm`命令删除abc.txt：`rm abc.txt`；  
方案3：`git rm`命令从版本库中删除`abc.txt`文件，接着`git commit`提交。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git rm abc.txt
    rm 'abc.txt'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "remove abc.txt"
    [master 1578051] remove abc.txt
     1 file changed, 1 deletion(-)
     delete mode 100644 abc.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git status
    On branch master
    nothing to commit, working directory clean

对于方案1和方案2，**Git**将知道我们删除了`abc.txt`文件，这样，**工作区 跟版本库**就形成不一致了。`git status` 将显示出哪些文件删除了。  
这样，因为版本库中还有`abc.txt`，在误删情况下，可用`git checkout -- abc.txt`命令恢复到最新版本。

对于方案3，文件将从版本库中删除，工作区中也删除。运行`git status`命令不会打印哪些文件被删除了。  
当然，方案3的替代做法是：手动删除文件后，接着使用`git rm filename`和`git add filename`，效果是一样的。

## 2.4 远程仓库 ##

这是 **Git**与SVN（集中式版本控制系统）等的最大区别。

**Git**是分布式版本控制系统，同一个Git仓库，可分布到不同的机器上。  
![在这里插入图片描述][70 3]  
某台机器拥有原始版本库，其他机器都可克隆此原始版本库，每台机器上的版本库是一样的，无主次之分。

### 2.4.1 GitHub账户 ###

可自行搭建一运行**Git**的服务器、也可使用**GitHub**（一个Git仓库托管平台），有了远程仓库，就不用担心充当服务器的机器坏了。每个人都可从远程仓库克隆版本库到自己机器上，并可各自将自己的提交推送到远程仓库，也可以从远程仓库拉取他人的提交。

1、在**GitHub**注册账号；  
2、创建**SSH Key**。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ ssh-keygen -t rsa -C "my-email@eaxmple.com"

一直回车，使用默认值。我的Win10将在`C:\Users\Administrator`目录下新增`.ssh`目录，里头有`id_rsa`、`id_rsa.pub`两个文件，这是SSH Key的密钥对，前者是私钥、后者是公钥。

3、登录**GitHub**，Setting，SSH and GPG keys，SSH key / Add new：完成添加。  
![在这里插入图片描述][70 4]  
这步操作的目的：由于本地**Git**仓库 与远程**GitHub**之间的传输是通过**SSH**加密的，**GitHub**根据公钥就能确定推送的提交是我推送的（而不是别人）。**Git**支持**SSH**协议。

**GitHub**允许添加多个Key，毕竟可能我有多台机器。

### 2.4.2 创建远程仓库 ###

**场景：**创建一个本地**Git**仓库 和 一个在**GitHub**上的**Git**仓库，两者远程同步，**GitHub**上的仓库既可作为备份，也可用于他人协作。

1、创建远程仓库  
![在这里插入图片描述][70 5]  
如此在**GitHub**上创建了一个空的`testGit`仓库。并将得到一个远程仓库URL。

2、添加到远程仓库（关联一个远程仓库）：`git remote add origin <远程仓库URL>`

git remote add origin https://github.com/czy0905/testGit.git

参数`origin`，表示远程仓库名字，这是**Git**约定成俗的，一看到它就知道是远程仓库。  
![在这里插入图片描述][70 6]  
PS：由于我没有添加**SSH key**到当前**GitHub**，所以出现上述需要输入**GitHub**账户名和密码。以及上述github URL是用的https协议（每次得输入口令。慢一些），而不是ssh协议（git://，速度快）。

3、将本地仓库所有内容推送到远程仓库：`git push`  
下方是将当前分支`master`推送到远程仓库。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git push -u origin master
    Username for 'https://github.com': <your-github-username>
    Counting objects: 17, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (10/10), done.
    Writing objects: 100% (17/17), 1.45 KiB | 0 bytes/s, done.
    Total 17 (delta 2), reused 0 (delta 0)
    remote: Resolving deltas: 100% (2/2), done.
    remote:
    remote: Create a pull request for 'master' on GitHub by visiting:
    remote:      https://github.com/<your-github-username>/testGit/pull/new/master
    remote:
    To https://github.com/<your-github-username>/testGit.git
     * [new branch]      master -> master
    Branch master set up to track remote branch master from origin.

此时刷新远程仓库URL，就可看到远程仓库的内容和本地仓库一样了：  
![在这里插入图片描述][70 7]  
今后，只要本地仓库进行了提交，就可以通过`git push`命令将本地`master`分支推送到**GitHub**。

### 2.4.3 远程仓库clone ###

先在**GitHub**创建一个新的仓库，名为`gitLearn`。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ cd D:\gitLearn
    
    Administrator@Cchen-PC MINGW64 /d/gitLearn
    $ git clone git@github.com:<your-github-username>/gitLearn

上述用的这种URL：`git@github.com:<your-github-username>/gitLearn`，SSH协议的。  
也可用：`https://github.com/<your-github-username>/gitLearn`，https协议。  
![在这里插入图片描述][70 8]

## 2.5 分支管理 ##

**场景：**多人协同开发某个应用程序。

### 2.5.1 创建和合并分支 ###

在创建、切换、删除分支操作上，**Git**都可快速完成。

每一次`git commit`提交，**Git**都将它们串成一条时间线，这条时间线 即为一个分支。上述例中到目前为止，只有一条时间线，这条分支称为 **主分支**，即`master`分支。`HEAD`严格意义上不是指向提交，它指向当前分支；`master`才是指向提交。

`master`分支是一条线，**Git**利用`master`指向最新的提交；再用`HEAD`指向`master`，就可确定当前分支、以及当前分支的提交点。  
![在这里插入图片描述][70 9]  
每提交一次，`master`分支将向前移动一步。随着不断提交，`master`分支的时间线将越来越长。

1、创建分支

当**创建一个新的分支**时（如：`dev`），**Git**将新建一个指针 `dev`，指向`master`相同的提交点，再将`HEAD`指向`dev`（表示当前分支在`dev`上）：  
![在这里插入图片描述][70 10]  
**Git**创建一个分支是极速的：增加一个分支的`dev`指针，更改`HEAD`指向；而工作区文件不用产生任何变化。

此时，对工作区的修改、提交都将针对`dev`分支。例如：**新提交一次，dev指针往前移动一步，但master指针是不变的。**  
![在这里插入图片描述][70 11]  
对应的创建分支`git`命令：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout -b dev
    Switched to a new branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $

`git checkout -b dev`命令表示创建dev分支，并切换到dev分支。等价于下方两个命令：

git branch dev # 创建分支
    git checkout dev # 切换到分支

查看当前分支命令：`git branch`，它会列出所有分支，并在当前分支前标 `*`。

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git branch
    * dev
      master

此时，可在dev分支上提交了，如对readme.txt修改1次。提交：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git commit -m "work on dev branch.Fifth commit."
    [dev fbb9f20] work on dev branch.Fifth commit.
     1 file changed, 2 insertions(+), 1 deletion(-)

现在`dev`分支工作已完成，可切换至`master`分支：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.

在切换到`master`分支后，用`cat readme.txt`命令查看文件内容，可发现刚才对其的修改是看不见的。原因是：对其修改的提交是`dev`分支进行的，而`master`分支此刻的提交点并未变动。如下图所示：  
![在这里插入图片描述][70 12]

2、合并分支

接着上例：在`dev`分支上工作完成了，需将`dev`分支的工作成果合并到`master`分支上。**Git**需要做的是直接将`master`指向`dev`的当前提交即可。这就是**合并分支**。  
![在这里插入图片描述][70 13]

合并分支命令：`git merge`，它用于合并指定分支到当前分支。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git merge dev
    Updating 1578051..fbb9f20
    Fast-forward
     readme.txt | 3 ++-
     1 file changed, 2 insertions(+), 1 deletion(-)

`Fast-foward` 表示为**快速模式**合并。  
此时，再用`cat readme.txt`命令查看文件内容，就可发现和`dev`分支的最新提交是一样的了。

如果现在不需要`dev`分支了，可使用删除分支命令：`git branch -d <分支名称>`。在删除分支后，查看分支情况，将看不到`dev`分支了。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git branch -d dev
    Deleted branch dev (was fbb9f20).
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git branch
    * master

### 2.5.2 解决分支冲突 ###

**案例**：  
1 新建并切换分支`branch_01`：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout -b branch_01
    Switched to a new branch 'branch_01'

2 修改`readme.txt`文件，新增一行；  
3 在`branch_01`分支上提交，然后切换回master分支：

Administrator@Cchen-PC MINGW64 /d/testGit (branch_01)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (branch_01)
    $ git commit -m "create branch_01.change readme.txt last line."
    [branch_01 82aee8f] create branch_01.change readme.txt last line.
     1 file changed, 2 insertions(+), 1 deletion(-)
    
    Administrator@Cchen-PC MINGW64 /d/testGit (branch_01)
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 1 commit.
      (use "git push" to publish your local commits)

上述打印`Your branch is ahead of 'origin/master' by 1 commit.`提示：当前本地的master分支 比远程仓库的master分支要超前一个提交。  
4 在`master`分支上将`readme.txt`文件中新增一行（注意 此时打开的文件是原来在`master`上的内容，并非在`branch_01`上的内容），然后提交：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "change readme.txt on master."
    [master 3c3830a] change readme.txt on master.
     1 file changed, 2 insertions(+), 1 deletion(-)

现在，`master`分支、`branch_01`分支各自分别有新的提交，如下图所示：  
![在这里插入图片描述][70 14]  
此时，Git是无法执行`Fast-forward`**快速模式**合并的。只能试图将各自的修改合并起来，但这样合并就很可能会有**冲突**：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git merge branch_01
    Auto-merging readme.txt
    CONFLICT (content): Merge conflict in readme.txt
    Automatic merge failed; fix conflicts and then commit the result.
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master|MERGING)
    $

**合并失败！！**注意观察显示分支的地方变成了 `master|MERGING`  
**Git**打印提示：`fix conflicts and then commit the result.`即解决冲突后再提交。

**对于上述这种案例，是很容易产生的。**  
`git status`命令可告知冲突的文件：

Administrator@Cchen-PC MINGW64 /d/testGit (master|MERGING)
    $ git status
    On branch master
    Your branch is ahead of 'origin/master' by 2 commits.
      (use "git push" to publish your local commits)
    You have unmerged paths.
      (fix conflicts and run "git commit")
    
    Unmerged paths:
      (use "git add <file>..." to mark resolution)
    
            both modified:   readme.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")

查看`readme.txt`文件内容：变成了这样。

Administrator@Cchen-PC MINGW64 /d/testGit (master|MERGING)
    $ cat readme.txt
    我的学习Git之路！
    我现在修改了。
    我的第3次修改！
    我是第4次修改的内容的一行。
    在dev分支上操作。第5次修改。
    <<<<<<< HEAD
    我是在创建branch_01分支后，在master分支上新增的一行哦。
    =======
    我在创建branch_01分支。
    >>>>>>> branch_01

**Git**使用`<<<<<<<`、`=======`、`>>>>>>>`来标记不同分支的内容。

解决冲突：  
1、修改并保存此时的`readme.txt`，即修改成所希望的内容。  
2、提交：

Administrator@Cchen-PC MINGW64 /d/testGit (master|MERGING)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master|MERGING)
    $ git commit -m "conflict fixed."
    [master 7540926] conflict fixed.
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git branch
      branch_01
    * master

使用`git log`命令可查看分支合并情况。`git log --graph`可查看分支合并图。

现在，`master`分支和`branch_01`分支将如下图所示：  
![在这里插入图片描述][70 15]

如果不需要`branch_01`分支了，可将其删除。

### 2.5.3 分支管理策略 ###

上一小节的`Fast-forward`**快速模式**合并的方案下，若删除了分支，也将会丢掉分支信息。

而强制禁用`Fast-forward`**快速模式**，**Git**将在`merge`时生成一个新的`commit`，从而可在分支历史上看出分支信息。

1、–no-ff模式  
下方介绍`--no-ff`模式的`git merge`：  
①仍然创建并切换`dev`分支：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout -b dev
    Switched to a new branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)

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

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git commit -m "branch strategy."
    [dev dbd4013] branch strategy.
     1 file changed, 1 insertion(+)

③切换回`master`分支，然后合并`dev`分支，使用`--no-ff`参数（即表示禁用`Fast-forward`）：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 4 commits.
      (use "git push" to publish your local commits)
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git merge --no-ff -m "merge with no-ff" dev
    Merge made by the 'recursive' strategy.
     readme.txt | 1 +
     1 file changed, 1 insertion(+)

上述合并会同时创建一个新的`commit`，因此加上`-m`参数，以便将`commit`描述写入。

合并后可使用`git log`命令查看分支历史：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git log --graph --pretty=oneline --abbrev-commit
    *   33e86b1 merge with no-ff
    |\
    | * dbd4013 branch strategy.
    |/
    *   7540926 conflict fixed.
    |\
    | * 82aee8f create branch_01.change readme.txt last line.
    * | 3c3830a change readme.txt on master.
    |/
    * fbb9f20 work on dev branch.Fifth commit.
    * 1578051 remove abc.txt
    * 7533102 add abc.txt
    * 089ee82 Fourth change for readme.txt and add LICENSE.
    * a0ee5d1 Third changed.
    * 71d82e9 second commit
    * 9679b2f my first git commit:readme.txt

上方在不使用`Fast-forward`模式下，`merge`过程如下图所示：  
![在这里插入图片描述][70 16]

2、分支策略

在实际开发过程中，应该按照一些基本原则进行**分支管理**：

首先、`master`分支本应是非常稳定的，即仅用来发布新版本，平常不可在`master`分支上工作；

平时工作都应在`dev`分支上，即`dev`分支是不稳定的。例如：发布1.0版本时，将`dev`分支合并到`master`分支上，在`master`分支发布1.0版本。

开发团队的每个人都在`dev`分支上工作，每个人都有自己的分支，每个人只须在完成自己的任务时往`dev`分支上合并即可。如下图所示：  
![在这里插入图片描述][70 17]

在合并分支时，加上`--no-ff`参数就能进行普通模式合并，合并后的历史有分支，可看出曾经做过分支；而`Fast-forward`合并是看不出曾经做过合并。

### 2.5.4 修复Bug的分支 ###

![在这里插入图片描述][70 18]  
在实际软件开发过程中，可能经常会有bug。每个bug都可通过一个新的临时分支进行修复，修复之后，合并分支，然后删除临时分支。

**场景：**研发经理发来一个修复bug代号为`crash_001`的任务，我立马创建一个`issue-crash_001`分支来修复该bug。但是，当前在`dev`分支上的工作进行到60%，无法提交。而bug须马上修复。

例：现在，切换到`dev`分支；并修改`readme.txt`文件和新建一个`hello.py`文件。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout dev
    Switched to branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git status
    On branch dev
    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:   readme.txt
    
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
    
            hello.py
    
    no changes added to commit (use "git add" and/or "git commit -a")

解决方案：**Git**提供了一个`stash`功能，它能将当前工作现场“贮藏”起来，等修复bug后可恢复现场继续工作：  
①`git stash`命令

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git stash
    Saved working directory and index state WIP on dev: dbd4013 branch strategy.
    HEAD is now at dbd4013 branch strategy.

此时，使用`git status`命令查看工作区，是干净的，可放心地创建分支来修复bug。  
②确定在哪个分支上修复bug，如需在`master`分支上修复bug，就从`master`创建临时分支：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 6 commits.
      (use "git push" to publish your local commits)
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout -b issue-crash_001
    Switched to a new branch 'issue-crash_001'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (issue-crash_001)
    $

③修复bug。例如 在`readme.txt`修改某行内容。然后提交：

Administrator@Cchen-PC MINGW64 /d/testGit (issue-crash_001)
    $ git add readme.txt
    
    Administrator@Cchen-PC MINGW64 /d/testGit (issue-crash_001)
    $ git commit -m "fix bug 001"
    [issue-crash_001 d3aa70c] fix bug 001
     1 file changed, 1 insertion(+), 1 deletion(-)

④bug修复后，切换到`master`分支，完成合并；最后删除`issue-crash_001`分支：

Administrator@Cchen-PC MINGW64 /d/testGit (issue-crash_001)
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 6 commits.
      (use "git push" to publish your local commits)
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git merge --no-ff -m "merged bug fix 001" issue-crash_001
    Merge made by the 'recursive' strategy.
     readme.txt | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)

⑤回到`dev`分支继续完成未剩余的工作。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git checkout dev
    Switched to branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git status
    On branch dev
    nothing to commit, working directory clean

上述可看到工作区是干净的。运用`git stash list`命令可查看刚才的工作现场存在何处：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git stash list
    stash@{0}: WIP on dev: dbd4013 branch strategy.
    stash@{1}: WIP on dev: dbd4013 branch strategy.

⑥恢复工作现场。上述可看到工作现场虽然还在，但是需要恢复一下，有两个方法：  
方法一：`git stash apply`命令用于恢复。不过在恢复后，`stash`内容并不会删除，需用`git stash drop`命令进行删除。  
方法二：直接用`git stash pop`命令，恢复的同时，将`stash`内容也删除。

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git stash pop
    On branch dev
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
    
            new file:   hello.py
    
    Dropped refs/stash@{0} (e84310d7ddd38ea0f53e01230e3b5d4e0ebbdd58)

此时，再用`git stash list`命令，将看不到`stash`内容了。可多次`stash`，在恢复时，可先用`git stash list`查看，后恢复指定的`stash`，使用`git stash apply stash@{0}`。

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git stash list
    stash@{0}: WIP on dev: dbd4013 branch strategy.

### 2.5.5 开发新功能的分支 ###

接到一个开发应用程序新功能的任务，名为Like（点赞功能），不过这个项目是带实验性质的，不一定将来会公开上线，需要进行一段时间验证。

因此，当然不能在主分支上进行，每添加一个新功能，就新建一个`feature`分支，在这开发，完成后，合并，最后删除`feature`分支。

①首先、创建新的`feature-Like`分支，并切换到`feature-Like`分支；

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout -b feature-Like
    Switched to a new branch 'feature-Like'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)

②开发新功能（即新增`like.py`），完成；  
③添加、提交：

Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)
    $ git add like.py
    
    Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)
    $ git status
    On branch feature-Like
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
    
            new file:   like.py
    
    
    Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)
    $ git commit -m "add new feature of Like"
    [feature-Like 005dec4] add new feature Like
     1 files changed, 1 insertions(+)
     create mode 100644 like.py

④**两种情况：**  
**情况1**：新功能Like确定了要公开发布。那么：  
切回`dev`分支，合并，删除`feature-Like`分支：

Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)
    $ git checkout dev
    Switched to branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git merge --no-ff -m "merged new feature of Like" feature-Like
    Merge made by the 'recursive' strategy.
     like.py | 1 +
     1 file changed, 1 insertion(+)
     create mode 100644 like.py

**情况2**：新功能Like取消，不发布了。得就地删除。那么：  
切回`dev`分支

Administrator@Cchen-PC MINGW64 /d/testGit (feature-Like)
    $ git checkout dev
    Switched to branch 'dev'
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git branch -d feature-Like
    error: The branch 'feature-Like' is not fully merged.
    If you are sure you want to delete it, run 'git branch -D feature-Like'.

**失败了！**提示`feature-Like`分支还未被合并，如果删除，将丢失掉修改；如果强行删除，需使用`-D`参数（大写的）。

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git branch -D feature-Like
    Deleted branch feature-Like (was 005dec4).

### 2.5.6 多人协作：推送和抓取分支 ###

当从远程仓库clone时，实质是**Git****自动将本地`master`分支与远程`master`分支**对应起来。远程仓库的默认名称为`origin`。  
查看远程仓库信息：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git remote -v
    origin  https://github.com/<your-github-username>/testGit.git (fetch)
    origin  https://github.com/<your-github-username>/testGit.git (push)

上述打印提示可**抓取、推送**的`origin` URL。当然，若没有推送权限，是看不到`push` URL的。

1、推送分支  
推送分支，即将**某分支上的所有本地提交**推送到远程仓库。推送时，需指定本地分支，从而**Git****会自动将该分支推送到远程仓库对应的远程分支上**。

场景1：推送`master`分支到远程仓库

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git push origin master
    Username for 'https://github.com': <your-github-username>
    Counting objects: 20, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (20/20), done.
    Writing objects: 100% (20/20), 1.94 KiB | 0 bytes/s, done.
    Total 20 (delta 7), reused 0 (delta 0)
    remote: Resolving deltas: 100% (7/7), done.
    To https://github.com/<your-github-username>/testGit.git
       1578051..69e6c1c  master -> master

查看URL：  
`https://github.com/<your-github-username>/testGit.git`，它是主分支。

场景2：推送其他分支（如`dev`分支）到远程仓库

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git push origin dev
    Username for 'https://github.com':<your-github-username>
    Counting objects: 4, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (4/4), 386 bytes | 0 bytes/s, done.
    Total 4 (delta 1), reused 0 (delta 0)
    remote: Resolving deltas: 100% (1/1), done.
    remote:
    remote: Create a pull request for 'dev' on GitHub by visiting:
    remote:      https://github.com/<your-github-username>/testGit/pull/new/dev
    remote:
    To https://github.com/<your-github-username>/testGit.git
     * [new branch]      dev -> dev

查看URL：  
`https://github.com/<your-github-username>/testGit/tree/dev`，它是子分支，默认这种格式。

不过，并不是非得把**本地分支**往远程仓库上推送，一般性原则：

*  `master`分支是**主分支**，需时刻保持与远程仓库同步；
 *  `dev`分支是**开发分支**，项目团队成员都在此分支上工作，因此需与远程仓库同步；
 *  `bug`分支只用于在本地修复bug，无需推送到远程仓库，除非领导要看修复了几个bug；
 *  `feature`分支是新功能开发分支，是否推送到远程仓库，取决于该功能是否与团队成员合作开发。

2、抓取分支

在多人协作时，团队成员一般都会往`master`、`dev`分支上推送各自的修改。

**模拟一个团队成员（名叫 大雕）**，即在另一台PC（将SSH Key添加到GitHub）、或同一电脑另一个目录下`clone`：  
选择后者，在D盘新建一个`otherTestGit`目录，然后：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ cd d:/otherTestGit
    
    Administrator@Cchen-PC MINGW64 /d/otherTestGit
    $ git clone https://github.com/<your-github-username>/testGit.git
    Cloning into 'testGit'...
    remote: Enumerating objects: 40, done.
    remote: Counting objects: 100% (40/40), done.
    remote: Compressing objects: 100% (23/23), done.
    remote: Total 40 (delta 11), reused 39 (delta 10), pack-reused 0
    Unpacking objects: 100% (40/40), done.
    Checking connectivity... done.

默认情况下，大雕在`clone`完成后，只能看到本地`master`分支。

Administrator@Cchen-PC MINGW64 /d/otherTestGit
    $ cd /d/otherTestGit/testGit
    
    Administrator@Cchen-PC MINGW64 /d/otherTestGit/testGit (master)
    $ git branch
    * master

现在，大雕要在`dev`分支上进行开发工作，则**必须创建远程仓库`origin`的`dev`分支到本地**：

Administrator@Cchen-PC MINGW64 /d/otherTestGit/testGit (master)
    $ git checkout -b dev origin/dev
    Branch dev set up to track remote branch dev from origin.
    Switched to a new branch 'dev'

接着，大雕就可以在`dev`分支上进行开发了（如对`like.py`文件增加了一些代码）。

然后，将`dev`分支`push`到远程仓库：

Administrator@Cchen-PC MINGW64 /d/otherTestGit/testGit (dev)
    $ git push origin dev
    Username for 'https://github.com': <your-github-username>
    Counting objects: 3, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 362 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To https://github.com/<your-github-username>/testGit.git
       6bdc675..4fd2a19  dev -> dev

大雕已完成 往`origin/dev`分支推送提交。而我（cc）也对`like.py`文件作了某些修改，并想推送到远程仓库：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git add like.py
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git commit -m "changed like.py file by cc."
    [dev 8e8b399] changed like.py file by cc.
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git push origin dev
    Username for 'https://github.com': <your-github-username>
    To https://github.com/<your-github-username>/testGit.git
     ! [rejected]        dev -> dev (fetch first)
    error: failed to push some refs to 'https://github.com/<your-github-username>/testGit.git'
    hint: Updates were rejected because the remote contains work that you do
    hint: not have locally. This is usually caused by another repository pushing
    hint: to the same ref. You may want to first integrate the remote changes
    hint: (e.g., 'git pull ...') before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

**失败了！error。**提示有其他人的最新提交 与我试图推送的提交之间有冲突。**Git**提示的解决方案是：先用`git pull`将最新的提交从`origin/dev`上抓取下来；然后在本地合并，解决冲突，再推送。

**首先、**设置指定本地`dev`分支 与远程仓库`origin/dev`分支的链接：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git branch --set-upstream-to=origin/dev dev
    Branch dev set up to track remote branch dev from origin.

**然后、**运行`git pull`命令：注意`dev|MERGING`这个变化。

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git pull
    Auto-merging like.py
    CONFLICT (content): Merge conflict in like.py
    Automatic merge failed; fix conflicts and then commit the result.
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev|MERGING)
    $

**接着、**手动解决冲突（即修改`like.py`成所希望的内容）：

**最后、**添加、提交，push：

Administrator@Cchen-PC MINGW64 /d/testGit (dev|MERGING)
    $ git add like.py
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev|MERGING)
    $ git commit -m "fix conflict of like.py file."
    [dev c5c07a9] fix conflict of like.py file.
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git push origin dev
    Username for 'https://github.com': <your-github-username>
    Counting objects: 6, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (5/5), done.
    Writing objects: 100% (6/6), 730 bytes | 0 bytes/s, done.
    Total 6 (delta 0), reused 0 (delta 0)
    To https://github.com/<your-github-username>/testGit.git
       4fd2a19..c5c07a9  dev -> dev

现在，在远程仓库就可以看到大雕和我（cc）对`like.py`文件合并后的内容了。

综上所述，**多人协作的工作模式**：

1.  试图使用`git push origin <branch-name>`推送自己的修改；
2.  如果推送失败，则多半是因为远程仓库分支比你的本地分支更加新，需要先使用`git pull`试图合并（若提示There is no tracking information for the current branch.，则表示本地分支与远程分支的链接关系未创建。需使用`git branch --set-upstream=origin/<branch-name> <branch-name>`进行创建）；
3.  如果合并有冲突，则得先解决冲突，并在本地提交；
4.  没有冲突、或解决冲突后，再使用`git push origin <branch-name>`推送就能成功。

## 2.6 标签（tag）管理 ##

发布某一个版本时，先在版本库中创建一个**tag**，如此，就唯一确定了创建**tag**时刻的版本。**tag**是版本库的一个快照。将来无论何时，取某个**tag**的版本，即将创建该**tag**时刻的历史版本取出来。

**Git**的**tag**虽然是版本库的快照，但其实它是指向某个`commit`的指针（跟分支很像），不过分支可以移动，**tag**不可移动。创建、删除**tag**都是可瞬间完成的。

场景：前面`commit id`是像`28859fc...`一长串的数字和字母。不好记。**tag**可以是一个有意义（易记住）的名称（如v1.0），它跟某个`commit`绑在一起。

### 2.6.1 创建标签（tag） ###

在**Git**中创建**tag**很简单。  
**首先、**切换到需要创建**tag**的分支上：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git branch
    * dev
      feature-Like
      issue-crash_001
      master
    
    Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.

**然后、**创建一个**tag**：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag v1.0

默认情况下，**tag**创建在最新提交的`commit`上的。

**接着、**可查看所有**tag**：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag
    v1.0

如何在指定的某个历史`commit`上创建**tag**？  
①切换到需要创建**tag**的分支上：

Administrator@Cchen-PC MINGW64 /d/testGit (dev)
    $ git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.

②找到历史提交的`commit id`：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git log --pretty=oneline --abbrev-commit
    69e6c1c merged bug fix 001
    d3aa70c fix bug 001
    33e86b1 merge with no-ff
    dbd4013 branch strategy.
    7540926 conflict fixed.
    ...

③例如对`merged bug fix 001`这次提交创建**tag**，对应的`commit id`是`69e6c1c`：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag v0.9 69e6c1c

④查看**tag**：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag
    v0.9
    v1.0

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

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git show v0.9
    commit 69e6c1cca6c80604411a83ed86e8748569182d7c
    Merge: 33e86b1 d3aa70c
    Author: chenchen <Email>
    Date:   Wed Sep 26 22:36:29 2018 +0800
    
        merged bug fix 001

创建带有说明的**tag**，`-a`参数指定**tag**名，`-m`参数指定说明文字：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag -a v0.1 -m "version 01. released." 3c3830a

查看说明文字：`git show <tagname>`

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git show v0.1
    tag v0.1
    Tagger: chenchen <Email>
    Date:   Thu Sep 27 16:01:05 2018 +0800
    
    version 01. released.
    
    commit 3c3830a3edca753544a34e178a96771af22657fa
    Author: chenchen <Email>
    Date:   Wed Sep 26 18:37:40 2018 +0800
    
        change readme.txt on master.
    
    diff --git a/readme.txt b/readme.txt
    index 25dc014..1fe74d9 100644
    ...

PS：**tag**总是和某个`commit`挂钩。如果这个`commit`既出现在`master`分支，又出现在`dev`分支，那么在这两个分支上都可以看到这个**tag**。

### 2.6.2 操作标签（tag） ###

如果**tag**创建错了，也可删除：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag -d v0.1
    Deleted tag 'v0.1' (was c2a7da2)

创建的**tag**只存储在本地，并不会自动推送到远程仓库。所以，创建错了的**tag**可在本地安全删除。

如果要推送某个**tag**到远程仓库，可使用`git push origin <tagname>`：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git push origin v1.0
    Username for 'https://github.com': <your-github-username>
    Total 0 (delta 0), reused 0 (delta 0)
    To https://github.com/<your-github-username>/testGit.git
     * [new tag]         v1.0 -> v1.0

一次性推送全部尚未推送到远程仓库的本地标签：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git push origin --tags
    Username for 'https://github.com': <your-github-username>
    Total 0 (delta 0), reused 0 (delta 0)
    To https://github.com/<your-github-username>/testGit.git
     * [new tag]         v0.9 -> v0.9

删除在远程仓库的**tag**，步骤：  
首先、在本地删除：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git tag -d v0.9
    Deleted tag 'v0.9' (was 69e6c1c)

然后、在远程仓库删除：

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git push origin :refs/tags/v0.9
    Username for 'https://github.com': <your-github-username>
    To https://github.com/<your-github-username>/testGit.git
     - [deleted]         v0.9

查看远程仓库的**tag**：点开【release】按钮就能看到。

## 2.7 自定义Git ##

##  ##

**Git**除了`user.name`和`user.email`这两个配置项。还有很多的配置项。

简单举例：  
1、文本编辑器。Git默认调用环境变量editor定义的值作为文本编辑器。如果没有定义，会调用vi进行创建、编辑、以及标签信息。使用core.editor改变默认编辑器：

git config --global core.editor emacs

2、分页器。比如运行如`log`、`diff`命令时，可设置该项为`more`（默认为 `less`）、也可设置为空字符串（即不管输出多少，都会一页显示所有内容）：

git config --global core.pager ''

3、着色。可输出加上颜色。  
打开默认所有默认终端的着色：`true`、`false`、`always`

git config --global color.ui true

等等，还有很多的配置项，可让工作更高效。

### 2.7.1 忽略特殊文件 ###

场景：在开发过程中，如某些文件（如保存了数据库密码的配置文件）需放在工作区，但是不能提交这些文件。

解决方案：  
1、在工作区根目录创建一个特殊的名为`.gitignore`文件。当然，它本身就会被放入版本库中，才起作用。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ touch .gitignore

2、编辑`.gitignore`文件，即将需要忽略（不提交）的文件名编入。可参考**GitHub**官方提供的[模板][Link 4]。如此，在提交时，**Git**将自动忽略这些文件，不会添加到版本管理中。

忽略文件的原则：

*  操作系统自动生成的文件；
 *  编译生成的中间文件、可执行文件，如Python编译产生的`.pyc`文件；
 *  带有敏感信息的配置文件，如存放密码的配置文件。

另外，`.gitignore`忽略规则有优先级、匹配语法等。可参考[文章][Link 5]。

3、将`.gitignore`提交到**Git**、`push`到远程仓库。

Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git add .gitignore
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git commit -m "add .gitignore"
    [master 49999e5] add .gitignore
     1 file changed, 2 insertions(+)
     create mode 100644 .gitignore
    
    Administrator@Cchen-PC MINGW64 /d/testGit (master)
    $ git push origin master
    Username for 'https://github.com': <your-github-username>
    Counting objects: 3, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 325 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To https://github.com/<your-github-username>/testGit.git
       69e6c1c..49999e5  master -> master

PS：  
情况1：如果某个文件被`.gitignore`忽略了，`add`不到**Git**。但确实需要`add`该文件，可用`git add -f <filename>`强制`add`到**Git**。  
情况2：如果发现`.gitignore`写得有文件（如某个规则写错了），可用`git check-ignore`命令进行检查。

### 2.7.2 配置别名和文件 ###

1、配置别名

比如`git status`命令，容易输错。可简化命令为`git st`。这就用到配置别名。其中，`--global`表示全局参数，即这台机器上所有**Git**仓库下都有效。

$ git config --global alias.st status

还有一些可简写如下：也可以简写成别的名。

$ git config --global alias.co checkout
    $ git config --global alias.ci commit
    $ git config --global alias.br branch

再如：将暂存区的修改撤销掉（unstage），重新放回工作区的命令 `git reset HEAD <filename>`。该命令简写配置如下

$ git config --global alias.unstage 'reset HEAD'

简写后是 `git unstage <filename>`。

接着例如：显示最后一次提交信息，可简写如下

$ git config --global alias.last 'log -1'

简写后是 `git last`。

最狠的配置别名：`git lg`

$ git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

2、配置文件

配置**Git**时，加上`--global`参数是针对当前用户起作用的；不加`--global`参数是只针对当前仓库起作用。

每个仓库的**Git**配置文件都放在`.git/config`文件中：

[core]
    	repositoryformatversion = 0
    	filemode = false
    	bare = false
    	logallrefupdates = true
    	symlinks = false
    	ignorecase = true
    	hideDotFiles = dotGitOnly
    [remote "origin"]
    	url = https://github.com/<your-github-username>/testGit.git
    	fetch = +refs/heads/*:refs/remotes/origin/*
    [branch "master"]
    	remote = origin
    	merge = refs/heads/master
    [branch "dev"]
    	remote = origin
    	merge = refs/heads/dev
    [alias]
    	st = status

其中，别名就在`[alias]`后面，要删除别名，直接将对应的行删除即可。

而当前用户的**Git**配置文件 放在用户主目录（如Win10，‪`C:\Users\Administrator\.gitconfig`）下的一个隐藏文件`.gitconfig`中：

[user]
    	name = user name
    	email = Email
    	eamil = Email
    [github]
    	user = username
    [color]
    	ui = true
    [alias]
    	st = status
    	lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
    	last = log -1

当然，配置别名 也可直接修改配置文件完成。

### 2.7.3 搭建Git服务器 ###

其实，远程仓库 除了24小时都可以提交各自的修改外，跟本地仓库并无其他区别。

场景：不想公开项目源代码，又不想给**GitHub**上付费，自己的命运自己掌握。

搭建属于自己的一台**Git**服务器作为私有仓库：  
1、准备一个运行Linux的机器（推荐Ubuntu或Debian）；  
2、安装`git`：

$ sudo apt-get install git

3、创建一个`git`用户，用于运行`git`服务：

$ sudo adduser git

4、创建证书登录：  
收集所有需要登录的用户的公钥（即 它们各自的`id_rsa.pub`文件），把所有公钥导入到`/home/git/.ssh/authorized_keys`文件里，一行一个。  
5、初始化**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

6、禁用`shell`登录：  
出于安全考虑，第3步创建的`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`每次一登录就自动退出。  
7、clone远程仓库：  
现在，可以通过`git clone`命令克隆远程仓库了，在各自的电脑上运行：

$ git clone git@server:/srv/sample.git
    Cloning into 'sample'...
    warning: You appear to have cloned an empty repository.

管理公钥

若团队不大，将每个人的公钥收集起来放到服务器的`/home/git/.ssh/authorized_keys`文件是可行的。

如果团队上百人，可使用[Gitosis][]进行管理公钥。

管理权限

为保护项目源码安全，知识版权很重要，需在版本控制系统中设置一套完善的权限控制，比如 每个人是否有读写权限，精确到某个分支，甚至某个目录下。

因为**Git**最初是为Linux源代码托管而开发的，所以**Git**也继承了开源社区的精神，不支持权限控制。

不过，因为**Git**支持钩子（hook），所以可在服务器端编写一系列脚本来控制提交等操作，达到权限控制的目的。[Gitolite][]工具就为此而生。

# 3、免费的远程仓库 #

## 3.1 GitHub ##

一直使用GitHub作为免费的远程仓库，应用于开源项目，是最佳之选。同时，GitHub还是一个开源协作社区，鉴于Git强大的clone和分支功能，使得每个人都可以自由地参与各种开源项目。**即我们可以参与其他人的开源项目、他人也可以参与我们的开源项目**。

**如何参与一个开源项目？以[tensorflow][]为例，步骤：**  
1、在tensorflow项目主页，点击`Fork`按钮就在自己账号下`clone` tensorflow仓库；  
2、将tensorflow从自己账号`clone`到本地，如此，就可以推送我的修改（如修复bug、新增功能）；而如果从作者仓库URL `clone`，是不能推送修改的，因为没有权限；  
3、如果希望tensorflow接受我的修改，可在GitHub发起一个`Pull requests`，等待对方接受即可。

## 3.2 码云 ##

国内Git托管服务平台：[码云][Link 1]，跟马云没关系！哈哈~

简直和GitHub一样。

参考：  
[Git官方网站][Git]

[70]: /images/20220510/58f9dc3b9b29405eb9c750e2aedc54ab.png
[GitHub]: https://github.com/
[Link 1]: https://gitee.com/
[CODING]: https://coding.net/
[Code]: https://code.aliyun.com/
[Link 2]: http://xiaolvyun.baidu.com/
[CodeHub]: https://www.huaweicloud.com/product/codehub.html
[Link 3]: https://git-scm.com/downloads
[70 1]: /images/20220510/3f576439d9f2449a968d6a65f8b9106c.png
[70 2]: /images/20220510/f4bf7361f6534705a51c5850a04e611d.png
[70 3]: /images/20220510/b93230552b924530b79cf6634e68da37.png
[70 4]: /images/20220510/2203c68284404694947ef7a0cabc2711.png
[70 5]: /images/20220510/1565883a69a54925b8c8d3e0291fcd61.png
[70 6]: /images/20220510/63e94e4300ab467cbad94e6f5f7b3ba3.png
[70 7]: /images/20220510/e7a7c5dd55f24adf90ae1962ee8c7859.png
[70 8]: /images/20220510/66b3dc4e8287496385159dbd9dc41f0c.png
[70 9]: /images/20220510/333426a61c684b6fb1564e6a77bdb1bc.png
[70 10]: /images/20220510/4f0aff821b1542acb919e354c2e45fe7.png
[70 11]: /images/20220510/3219292ab5e04791828f1c594fee068c.png
[70 12]: /images/20220510/fb73413e850549b1b01c7599d8d7b3c9.png
[70 13]: /images/20220510/87f4d7d4454642e59f4d33b4996e8ad4.png
[70 14]: /images/20220510/b5a66381b800431cb886c2ff69512505.png
[70 15]: /images/20220510/a22d848c5d2149579f98de0454be72c2.png
[70 16]: /images/20220510/ac5cb0e61f8a405f869aa969da8ab93e.png
[70 17]: /images/20220510/bb71a7fea87c4fa58c7b012c364c5b21.png
[70 18]: /images/20220510/1ce6f1dd685140fba845ef35ca0252b0.png
[Link 4]: https://github.com/github/gitignore
[Link 5]: https://www.cnblogs.com/kevingrace/p/5690241.html
[Gitosis]: https://github.com/res0nat0r/gitosis
[Gitolite]: https://github.com/sitaramc/gitolite
[tensorflow]: https://github.com/tensorflow/tensorflow
[Git]: https://git-scm.com/