Git完全指南

Git

一、学习目标

了解Git的历史、安装、基本操作、高级命令。

二、基础知识

2.1版本控制工具

版本控制是一种记录一个或若干个文件内容变化，以便将来查阅特定版本修订情况的系统。

2.1.1版本控制发展

2.1.1.1本地版本控制系统

许多人习惯用复制整个项目目录的方式保存不同的版本，为了区别和方便查重会加上备份的时间。这样虽然容易简单，但是容易犯错。有时候会混淆所在的工作目录，不小心就会写错文件或者覆盖意外的文件。
为了解决上述的问题，人们就开发了本地版本控制系统，大多数都是采用简单的数据库来记录文件的历史更新差异。其中最流行的是RCS。

2.1.1.2集中式版本控制系统

本地版本控制系统不能解决不同系统上的开发者协同工作。于是集中式版本系统就诞生。 这一类系统例如CVS/Subversion以及Perforce等，都有一个单一的集中管理服务器，保存所有的修订版本。协同工作的人们通过客户端连接这台集中管理服务器，拉去最新的文件或者提交更新。在很长的一段时间着都是版本控制系统的标准做法。

集中式版本控制系统对于本地版本控制系统来说带来了很多好处。协同的每个人都可以看到项目中其他人的工作和提交。管理员也可以把控每一个开发的权限，所有人公用一个版本管理服务器。节约了在本地的资源浪费和无法共享的问题。

当然集中式版本管理系统也有坏的方面。中央服务器会出现单点故障，如果故障一小时，那么在这个小时内，谁都无法提交和更新，也无法协同工作。如果中心服务器磁盘损坏并且没有备份，那么将丢失所有的数据，包括项目的整个变更历史。

2.1.1.3分布式版本控制系统

基于本地、集中式版本管理系统的缺陷，分布式版本控制系统面世了。在这一类系统中，像git、mercurial、bazaari以及darcs等。客户端并不只保存最新版本的文件快照，而是把代码仓库的完整镜像下来。这样一来，任何一处协同工作用的服务器故障，事后都可以使用任意一个镜像出来的本地仓库恢复。

2.2git和github

2.2.1git简史

同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。
Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：
• 速度
• 简单的设计
• 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
• 完全分布式
• 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统。

2.2.2github

GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名GitHub。

GitHub于2008年4月10日正式上线，除了Git代码仓库托管及基本的 Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。

由于github支持开源的项目，所以很多大企业都会将开源的项目源码放到github上，可以任意下载和学习。

2.2.3git和github的区别和联系

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。简单的说有了Git就可以将代码恢复到任何修改版本的代码。

GitHub是一个开源项目托管平台，简单说就是一个可以放代码的地方。

Git和GitHub具体来说是没有任何关系，只不过是GitHub只支持Git版本库的格式进行托管。Git是Linux组织开发的，而GitHub是企业开发的项目，目前已经被微软收购。

2.3git安装

2.3.1git下载

打开Git官网

2.3.2git安装

2.4git配置

本教程使用github作为公共仓库托管中心。

2.4.1github注册

打开github官网

2.4.2git配置

Win系统桌面右键→Git Base Here，打开git的命令行界面。
输入$ git config -l，执行该命令后将显示出git的配置信息，其中user.name=和user.email=是git仓库的用户名称和注册邮箱，如果没有该选项，那么就是没有设置账号密码。设置命令如下：

$ git config [--global][--system] user.name "zhichunqiu"     -- 设置名称
$ git config [--global][--system] user.email "[email protected]"  -- 设置邮箱
--global参数是设置全局的参数
--system参数是设置当前操作目录的局部参数

错误解决方法：

fatal: not in a git directory
该错误是由于打开的git命令行界面不在git目录下，所以需要切换到对应的git目录。
解决方法一：
如果电脑中有git目录文件夹（含有.git文件夹的目录），只需要在该目录下右键->git base here打开即可。

解决方法二：
如果电脑中没有git目录文件夹，那么创建一个git2019的文件夹目录，打开git base here窗口，执行git init初始化即可，则就是一个git目录文件夹了。

其他操作命令：
删除配置信息：

$ git config [--global][--system] --unset user.name  删除user.name参数的配置信息，如果没有--global、--system参数，那么默认删除--system的局部信息。

删除所有的指令：git config --unset-all user.name，将删除全局，本地等该参数的所有环境。

2.5git仓库目录结构

|–.git
|–HEAD #这个git项目当前处于那个分支
|–config #项目配置信息，git config命令会改变它
|–description #项目的描述信息
|–hooks/ #系统默认的钩子脚本目录
|–objects/ #Git本地仓库的所有对象（commits,trees,blobs,tags）
|–refs/ #标识你项目里面的每一个分支指向了哪一个提交
|–info/ #项目的基础信息，例如忽略提交等

2.6git仓库管理结构

2.7git协议

git可以使用四种主要的协议来传输资料：本地协议、HTTP协议、SSH协议以及Git协议。在此，将讨论不同协议的使用场景。

2.7.1本地协议

2.7.1.1基本知识

最基本的就是 本地协议（Local protocol） ，其中的远程版本库就是硬盘内的另一个目录。 这常见于团队每一个成员都对一个共享的文件系统（例如一个挂载的 NFS）拥有访问权，或者比较少见的多人共用同一台电脑的情况。 后者并不理想，因为你的所有代码版本库如果长存于同一台电脑，更可能发生灾难性的损失。

如果你使用共享文件系统，就可以从本地版本库克隆（clone）、推送（push）以及拉取（pull）。 像这样去克隆一个版本库或者增加一个远程到现有的项目中，使用版本库路径作为 URL。 例如，克隆一个本地版本库，可以执行如下的命令：

$ git clone /opt/git/project.git

或你可以执行这个命令：

$ git clone file:///opt/git/project.git

如果在 URL 开头明确的指定 file://，那么 Git 的行为会略有不同。 如果仅是指定路径，Git 会尝试使用硬链接（hard link）或直接复制所需要的文件。 如果指定 file://，Git 会触发平时用于网路传输资料的进程，那通常是传输效率较低的方法。 指定 file:// 的主要目的是取得一个没有外部参考（extraneous references）或对象（object）的干净版本库副本– 通常是在从其他版本控制系统导入后或一些类似情况需要这么做。 在此我们将使用普通路径，因为这样通常更快。

要增加一个本地版本库到现有的 Git 项目，可以执行如下的命令：

$ git remote add local_proj /opt/git/project.git

然后，就可以像在网络上一样从远端版本库推送和拉取更新了。

2.7.1.2优点

基于文件系统的版本库的优点是简单，并且直接使用了现有的文件权限和网络访问权限。 如果你的团队已经有共享文件系统，建立版本库会十分容易。 只需要像设置其他共享目录一样，把一个裸版本库的副本放到大家都可以访问的路径，并设置好读/写的权限，就可以了， 我们会在 在服务器上搭建 Git 讨论如何导出一个裸版本库。

这也是快速从别人的工作目录中拉取更新的方法。 如果你和别人一起合作一个项目，他想让你从版本库中拉取更新时，运行类似 git pull /home/john/project 的命令比推送到服务器再取回简单多了。

2.7.1.3缺点

这种方法的缺点是，通常共享文件系统比较难配置，并且比起基本的网络连接访问，这不方便从多个位置访问。如果你想从家里推送内容，必须先挂载一个远程磁盘，相比网络连接的访问方式，配置不方便，速度也慢。

值得一提的是，如果你使用的是类似于共享挂载的文件系统时，这个方法不一定是最快的。 访问本地版本库的速度与你访问数据的速度是一样的。 在同一个服务器上，如果允许 Git 访问本地硬盘，一般的通过 NFS 访问版本库要比通过 SSH 访问慢。

最终，这个协议并不保护仓库避免意外的损坏。 每一个用户都有“远程”目录的完整 shell 权限，没有方法可以阻止他们修改或删除 Git 内部文件和损坏仓库。

2.7.2HTTP协议

2.7.2.1基本知识

Git 通过 HTTP 通信有两种模式。 在 Git 1.6.6 版本之前只有一个方式可用，十分简单并且通常是只读模式的。Git 1.6.6 版本引入了一种新的、更智能的协议，让 Git 可以像通过 SSH 那样智能的协商和传输数据。 之后几年，这个新的 HTTP 协议因为其简单、智能变的十分流行。 新版本的 HTTP 协议一般被称为“智能” HTTP 协议，旧版本的一般被称为“哑” HTTP 协议。 我们先了解一下新的“智能” HTTP 协议。

2.7.2.1.1智能（Smart）HTTP协议

“智能” HTTP 协议的运行方式和 SSH 及 Git 协议类似，只是运行在标准的 HTTP/S 端口上并且可以使用各种HTTP 验证机制，这意味着使用起来会比 SSH 协议简单的多，比如可以使用 HTTP 协议的用户名／密码的基础授权，免去设置 SSH 公钥。

智能 HTTP 协议或许已经是最流行的使用 Git 的方式了，它即支持像 git:// 协议一样设置匿名服务，也可以像SSH 协议一样提供传输时的授权和加密。 而且只用一个 URL 就可以都做到，省去了为不同的需求设置不同的URL。 如果你要推送到一个需要授权的服务器上（一般来讲都需要），服务器会提示你输入用户名和密码。 从服务器获取数据时也一样。

2.7.2.1.2哑（Dumb）HTTP协议

如果服务器没有提供智能 HTTP 协议的服务，Git 客户端会尝试使用更简单的“哑” HTTP 协议。 哑 HTTP 协议里 web 服务器仅把裸版本库当作普通文件来对待，提供文件服务。 哑 HTTP 协议的优美之处在于设置起来简单。 基本上，只需要把一个裸版本库放在 HTTP 根目录，设置一个叫做 post-update 的挂钩就可以了（见 Git钩子）。 此时，只要能访问 web 服务器上你的版本库，就可以克隆你的版本库。 下面是设置从 HTTP 访问版本库的方法：

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

这样就可以了。 Git 自带的 post-update 挂钩会默认执行合适的命令（git update-server-info），来确保通过 HTTP 的获取和克隆操作正常工作。 这条命令会在你通过 SSH 向版本库推送之后被执行；然后别人就可以通过类似下面的命令来克隆：

$ git clone https://example.com/gitproject.git

通常的，会在可以提供读／写的智能 HTTP 服务和简单的只读的哑 HTTP 服务之间选一个。 极少会将二者混合提供服务。

2.7.2.2优点

我们将只关注智能 HTTP 协议的优点。
不同的访问方式只需要一个 URL 以及服务器只在需要授权时提示输入授权信息，这两个简便性让终端用户使用Git 变得非常简单。 相比 SSH 协议，可以使用用户名／密码授权是一个很大的优势，这样用户就不必须在使用Git 之前先在本地生成 SSH 密钥对再把公钥上传到服务器。 对非资深的使用者，或者系统上缺少 SSH 相关程序的使用者，HTTP 协议的可用性是主要的优势。 与 SSH 协议类似，HTTP 协议也非常快和高效。

你也可以在 HTTPS 协议上提供只读版本库的服务，如此你在传输数据的时候就可以加密数据；或者，你甚至可以让客户端使用指定的 SSL 证书。

另一个好处是 HTTP/S 协议被广泛使用，一般的企业防火墙都会允许这些端口的数据通过。

2.7.2.3缺点

在一些服务器上，架设 HTTP/S 协议的服务端会比 SSH 协议的棘手一些。 除了这一点，用其他协议提供 Git 服务与 “智能” HTTP 协议相比就几乎没有优势了。

如果你在 HTTP 上使用需授权的推送，管理凭证会比使用 SSH 密钥认证麻烦一些。 然而，你可以选择使用凭证存储工具，比如 OSX 的 Keychain 或者 Windows 的凭证管理器。 参考 凭证存储 如何安全地保存 HTTP 密码。

2.7.3SSH协议

2.7.3.1基本知识

架设 Git 服务器时常用 SSH 协议作为传输协议。 因为大多数环境下服务器已经支持通过 SSH 访问 —— 即使没有也很容易架设。 SSH 协议也是一个验证授权的网络协议；并且，因为其普遍性，架设和使用都很容易。
通过 SSH 协议克隆版本库，你可以指定一个 ssh:// 的 URL：

$ git clone ssh://user@server/project.git

或者使用一个简短的 scp 式的写法：

$ git clone user@server:project.git

你也可以不指定用户，Git 会使用当前登录的用户名。

2.7.3.2优点

用 SSH 协议的优势有很多。 首先，SSH 架设相对简单 —— SSH 守护进程很常见，多数管理员都有使用经验，并且多数操作系统都包含了它及相关的管理工具。 其次，通过 SSH 访问是安全的 —— 所有传输数据都要经过授权和加密。 最后，与 HTTP/S 协议、Git 协议及本地协议一样，SSH 协议很高效，在传输前也会尽量压缩数据。

2.7.3.3缺点

SSH 协议的缺点在于你不能通过他实现匿名访问。 即便只要读取数据，使用者也要有通过 SSH 访问你的主机的权限，这使得 SSH 协议不利于开源的项目。 如果你只在公司网络使用，SSH 协议可能是你唯一要用到的协议。如果你要同时提供匿名只读访问和 SSH 协议，那么你除了为自己推送架设 SSH 服务以外，还得架设一个可以让其他人访问的服务。

2.7.4Git协议

2.7.4.1基本知识

接下来是 Git 协议。 这是包含在 Git 里的一个特殊的守护进程；它监听在一个特定的端口（9418），类似于SSH 服务，但是访问无需任何授权。 要让版本库支持 Git 协议，需要先创建一个 git-daemon-export-ok 文件 —— 它是 Git 协议守护进程为这个版本库提供服务的必要条件 —— 但是除此之外没有任何安全措施。 要么谁都可以克隆这个版本库，要么谁也不能。 这意味着，通常不能通过 Git 协议推送。 由于没有授权机制，一旦你开放推送操作，意味着网络上知道这个项目 URL 的人都可以向项目推送数据。 不用说，极少会有人这么做。

2.7.4.2优点

目前，Git 协议是 Git 使用的网络传输协议里最快的。 如果你的项目有很大的访问量，或者你的项目很庞大并且不需要为写进行用户授权，架设 Git 守护进程来提供服务是不错的选择。 它使用与 SSH 相同的数据传输机制，但是省去了加密和授权的开销。

2.7.4.3缺点

Git 协议缺点是缺乏授权机制。 把 Git 协议作为访问项目版本库的唯一手段是不可取的。 一般的做法里，会同时提供 SSH 或者 HTTPS 协议的访问服务，只让少数几个开发者有推送（写）权限，其他人通过 git:// 访问只有读权限。 Git 协议也许也是最难架设的。 它要求有自己的守护进程，这就要配置 xinetd 或者其他的程序，这些工作并不简单。 它还要求防火墙开放 9418 端口，但是企业防火墙一般不会开放这个非标准端口。 而大型的企业防火墙通常会封锁这个端口。

2.8第一个Git项目

在这里，我们创建一个单独的文件夹单独体验Git。总之先从一个简单的小项目开始。在这个小示例中，first-git目录只有两个空的文本文件，如图2.8.1所示。

图 2.8.1

2.8.1创建版本库

现在需要创建一个版本库，用于存储改项目本身及其历史。Git中使用init命令初始化。

$ cd /d/git2019/first-git/

$ git init
Initialized empty Git repository in D:/git2019/first-git/.git/

init命令会在上述目录中创建一个名为.git的隐藏目录，并在其中创建一个版本库。如图2.8.1.1所示。

图2.8.1.1

2.8.2首次提交

我们将foo.txt和bar.txt两个文件添加到版本库中去。在git中，提交分为两个步骤。第一步：使用add命令添加需要提交的文件。第二步：使用commit命令将文件提交到版本库中。

$ git add --all

# --all参数表示将所有文件添加

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   bar.txt
        new file:   foo.txt

# --status命令查看当前状态，bar.txt和foo.txt文件已经添加

$ git commit --message "第一次提交"
[master (root-commit) 4b38244] 第一次提交
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar.txt
 create mode 100644 foo.txt

# --message参数是给提交添加备注

三、git基本命令

3.1初始化（本地）init

Git初始化仓库的命令是git init。如下：

$ git init

3.2初始远程仓库（github）remote

这里将本地初始化的文件推送到远程仓库github。首先需要在github中创建一个Repositories仓库，这里使用命名为github201901。复制项目的地址：https://github.com/zhichunqiu/github201901.git

$ git remote add origin https://github.com/zhichunqiu/github201901.git

# remote确认连接远程的仓库是那个，这里就是在github创建的仓库地址。

lenovo@DESKTOP-K59VO2B MINGW64 /d/git2019/first-git (master)
$ git push origin master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 235 bytes | 235.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: This repository moved. Please use the new location:
remote:   https://github.com/zhichunqiu/github201901.git
To https://github.com/zhichunqiu/github2019.git
 * [new branch]      master -> master

# git push origin master命令将本地的master分支推送给到远程，其他是打印的信息。

3.3本地提交add/commit

图3.3.1

git的整体流程如图3.3.1所示。我们在git2019/first-git目录下创建一个git-add.txt文件。

$ ls
bar.txt  foo.txt  git-add.txt

# ls命令可以看到目录下的所有文件，已经有了git-add.txt文件。

Git status命令可以查看到当前工作区的文件状态。

$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        git-add.txt

nothing added to commit but untracked files present (use "git add" to track)

# git status命令结果显示Untracked files就是没有加入版本库的文件，git-add.txt，提示建议我们使用git add <file>命令包含文件到即将commit中。

Git add命令添加文件，前面使用了–all参数将所有文件添加，这里只需要添加git-add.txt文件即可。Add只是做提交前的一个准备而已。

$ git add git-add.txt

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

        new file:   git-add.txt


# 添加有使用git status命令结果是Changes to be committed，说明git-add.txt文件已经添加了。

Git commit命令可以将add的文件提交到本地仓库中去了。

$ git commit --message "添加新的文件git-add.txt"
[master 54d6d90] 添加新的文件git-add.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 git-add.txt

# commit命令后面的--message参数是对本次提交的版本说明。

3.4信息查询status/reset/log

Git status命令用于查看当前工作区的文件情况。–short是简洁参数。

$ git status
On branch a-branch
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

        modified:   copy-c.txt

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:   c.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        copy-c.txt.orig
        readme.md

被提交的修改（hanges to be committed）：这部分将列出那些将在下次提交中被纳入版本库中的、被修改的文件。
不会被更新的修改（Changes not staged for commit）：这部分将列出那些已被修改，但尚未被注册到下次提交中的文件。
未被跟踪的文件（Untracked files）：这部分将列出所有的新增文件，但是没有被追踪。

Git reset命令更新状态，取消加入下一次提交的文件。

$ git reset HEAD copy-c.txt
Unstaged changes after reset:
M       c.txt
M       copy-c.txt

$ git status
On branch a-branch
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

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:   c.txt
        modified:   copy-c.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        copy-c.txt.orig
        readme.md

copy-c.txt文件已经被移动到了Changes not staged for commit:区域不会被提交。

Git log查看提交的历史。

$ git log
commit f610a36cb3ceba8fcd19d11a4b83e56eb6dbca0a (HEAD -> a-branch)
Author: jack <zzz>
Date:   Thu Sep 26 11:09:33 2019 +0800

    a-branch分支冲突

3.5撤销操作

Git commit --amend可以处理修改提交的备注信息和覆盖前面的commit。

修改提交注释
/e/git/projects/first-steps (a-branch)
$ git add ./

/e/git/projects/first-steps (a-branch)
$ git commit --message "撤销操作"
[a-branch cc585fa] 撤销操作
 3 files changed, 3 insertions(+), 1 deletion(-)

上述中提交的备注信息“撤销操作”，如果需要修改这个注释可以使用--amend参数。将会使用vim的方式打开信息，根据linux的vim命令修改后保存即可。
$ git commit --amend
[a-branch af2f51f] 测试撤销操作
 Date: Wed Oct 23 16:38:05 2019 +0800
 3 files changed, 3 insertions(+), 1 deletion(-)

操作完上述后，新增一个d.txt文件，但是想一起提交。
$ git add ./

/e/git/projects/first-steps (a-branch)
$ git commit --amend
[a-branch 6c821ee] 测试撤销操作
 Date: Wed Oct 23 16:38:05 2019 +0800
 4 files changed, 4 insertions(+), 1 deletion(-)

这样即使添加了d.txt文件，使用git commit --amend命令文件会和上一次提交捆绑在一起。

3.6暂存

储藏工作

有时候一个分支修改了部分内容，如果不提交想切换到另外一个分支是不允许的。可以使用git stash命令将修改的内容存入暂存区。暂存区是一个栈的数据结构，普通操作就是压栈和弹栈。

数据保存到暂存区

$ git stash
Saved working directory and index state WIP on a-branch: 6c821ee 测试撤销操作

现在暂存区域的内容
$ git stash list
stash@{0}: WIP on a-branch: 6c821ee 测试撤销操作

弹出指定的暂存内容
$ git stash pop stash@{0}
On branch a-branch
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:   a.txt
        modified:   b.txt
        modified:   c.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped stash@{0} (f922d1016d52bf17ea12fedca2ac18751c10b000)

3.7分支管理

创建

创建分支之前需要查看当前的分支情况。Git branch -a命令可以查看所有的本地和远程分支。

$ git branch -a
* a-branch
  b-branch
  c-branch
  d-branch
  master
当前所处的分支是a-branch

Git checkout master是切换到master分支
$ git checkout master
Switched to branch 'master'

-b参数指定创建分支后同时切换到最新分支。新分支名称为X-branch，以master分支创建新分支。
$ git checkout -b X-branch master
Switched to a new branch 'X-branch'

删除

如果使用-d参数删除，分支如何没有和其他分支合并过，就会出现下面的错误。如果确定分支不需要合并直接删除，可以改成使用-D参数。
$ git branch -d a-branch
error: The branch 'a-branch' is not fully merged.
If you are sure you want to delete it, run 'git branch -D a-branch'.

$ git branch -D a-branch
Deleted branch a-branch (was 6c821ee).

合并与冲突

使用当前分支合并b-branch分支，出现冲突会提示如下。同时冲突的文件会标有黄色的谈好，需要自己去手动处理冲突。
$ git merge b-branch
Auto-merging b.txt
CONFLICT (content): Merge conflict in b.txt
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

git mergetool工具解决冲突，冲突解决的时候会生成3个文件（各分支一个，分支合并的一个），选择文件后就是使用vim命令处理文件。合并冲突后会生成.orig文件，是合并前的原文件。
$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc codecompare smerge emerge vimdiff
Merging:
a.txt
b.txt

Normal merge conflict for 'a.txt':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (vimdiff): a.txt
还有 4 个文件等待编辑

Normal merge conflict for 'b.txt':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (vimdiff): b.txt
还有 4 个文件等待编辑

3.8远程提交/合并

本地分支提交信息推送到远程
$ git push origin 本地分支名称

3.9删除分支的恢复

查看分支情况
$ git reflog
4be25b4 (HEAD -> c-branch) HEAD@{0}: commit: c分支
51bb833 (d-branch) HEAD@{1}: checkout: moving from b-branch to c-branch
0567ec4 (b-branch) HEAD@{2}: commit: b分支
51bb833 (d-branch) HEAD@{3}: checkout: moving from master to b-branch
e5effe9 (master, X-branch) HEAD@{4}: checkout: moving from X-branch to master
e5effe9 (master, X-branch) HEAD@{5}: checkout: moving from master to X-branch
e5effe9 (master, X-branch) HEAD@{6}: checkout: moving from a-branch to master
6c821ee HEAD@{7}: reset: moving to HEAD
6c821ee HEAD@{8}: reset: moving to HEAD
6c821ee HEAD@{9}: commit (amend): 测试撤销操作
af2f51f HEAD@{10}: commit (amend): 测试撤销操作
cc585fa HEAD@{11}: commit: 撤销操作
8649811 HEAD@{12}: commit (amend): 测试一下撤销操作
37d332e HEAD@{13}: commit (amend): 测试一下撤销操作
f3e54c1 HEAD@{14}: commit (amend): 测试一下撤销操作
40023aa HEAD@{15}: commit (amend): 测试撤销操作
7430ce9 HEAD@{16}: commit (merge): 测试撤销操作
f610a36 HEAD@{17}: commit: a-branch分支冲突
6c732d8 HEAD@{18}: checkout: moving from master to a-branch
e5effe9 (master, X-branch) HEAD@{19}: commit: 冲突演示
6c732d8 HEAD@{20}: merge a-branch: Fast-forward
238b8ae (tag: v2019.09.26.10.56.001) HEAD@{21}: checkout: moving from a-branch to master

使用7430ce9该分支，分支名称为c-master
$ git checkout -b c-master 7430ce9
Switched to a new branch 'c-master'

3.10标签管理

查询标签

$ git tag
v2019.09.26.10.56.001

创建标签

Administrator@MINGW64 /e/git/projects/first-steps (c-master)
$ git tag 1.2.3.4 c-master -m "创建标签"

Administrator@MINGW64 /e/git/projects/first-steps (c-master)
$ git tag
1.2.3.4
v2019.09.26.10.56.001

推送标签

$ git push origin 1.2.3.4
也可以使用--tags参数的push命令推送被传分支的标签
$ git push --tags

删除标签

$ git tag -d 1.2.3.4
Deleted tag '1.2.3.4' (was 4c9827a)

Administrator@MINGW64 /e/git/projects/first-steps (c-master)
推送标签到远程
$ git push origin :refs/tags/1.2.3.4

3.11忽略文件

Git中不需要追踪的文件可以在.gitignore文件中配置，这样就会忽略对应的文件。

# 以'#' 开始的行，被视为注释.
# 忽略掉所有文件名是 foo.txt 的文件.
foo.txt
# 忽略所有生成的 html 文件,
*.html
# foo.html是手工维护的，所以例外.
!foo.html
# 忽略所有.o 和 .a文件.
*.[oa]