今年下半年，中日合拍的《Git游记》即将正式开机，我将…（上集）

今年下半年，中日合拍的《Git游记》即将正式开机，我将…（上集）

标签： 2018

---

一回首，2018年就剩下10天啦，看到很多巨佬都在发技术总结的文章，反观自己这只鶸(ruò)，
技术没啥长进，摸鱼摸了一年，惭愧。琢磨着硬撸也要撸一篇总结的文章，不然有种2018白过的感觉。
至于选Git的理由：

• 很多用Git的童鞋还停留在git pull和push等基本操作的程度。

行吧，上面的内容都是我「瞎编」的，「瞎编不是改编，胡说不是戏说」。

本来想一篇写完的，不过内容着实太多了，索性就分开两篇发了，上集讲述的姿势点：

---

Git概述——分布式版本控制系统

---

弄清楚Git相关的概念，有助于我们后续对于命令的掌握。

1. 什么是版本管理系统

Version Control System，简称VCS，一种用于记录一个或多个文件内容变化
历史，以便将来能对特定版本的历史记录进行查看，更改，备份还原的系统。
可以类比成「游戏存档」，特定时间结点：比如打Boss前存档，如果GG了，重新
读档就好了；还比如分支剧情，想体验不同选择触发的不同的剧情，存多个档，想玩
哪个档读哪个档。

VCS一般分为以下三类：

• 1.本地VCS

使用简单的数据库来记录文件的历史更新差异，比如RCS。

• 2.集中式VCS

用一个服务器来保存所有文件的修订版本，协同工作的人连接这个服务器，
获取或提交文件更新，比如SVN。

这种协同方式有个两个明显的缺点：
1.「需要联网」：同步和推送更新速度受带宽限制，内网还好，外网可能会有点慢了（大文件）；
2.「依赖中央服务器」：每个人的本地只有以前所同步的版本，如果服务器宕(dang)机了，谁都无法获取或提交更新。

• 3.分布式VCS

每个用户拥有完整的提交历史，支持离线提交更改，查看历史提交记录等。中央服务器更多的只是用作更改合并，同步的工具，比如Git。

从根本上来说，Git是一个内存寻址的文件系统，根据文件的Hash值来定位文件。
这个40位的Hash值使用SHA1算法生成，由两部分拼接：
header = “” + content.length + "\0"
(参数依次为：对象类型，数据字节长度，空字节~用于分隔header与content)
hash = sha1(header+content)，这里的拼接是二进制级别的拼接，而非字符串拼接。

2. Git与SVN的区别

Git和SVN除了上面说的联网需求不同外，还有「存储差异」：

SVN关心：文件内容的具体差异；而Git关心：文件整体是否发生改变。
SVN每次提交记录的是：「哪些文件进行了修改，修改了哪些行的哪些内容」。

如图，Version 2中记录的是文件A和C的变化，而Version 3中记录文件C的变化，以此类推；
而Git中，并不保存这些前后变换的差异数据，而是保存整个缓存区中的所有文件，
又称快照，「有变化的文件保存，没变化的文件不保存，而是对上次保存的快照做一个链接」，
因为这种不同的保存方式，使得Git切换分支的速度比SVN快上不少。

当然SVN也有它的优点，比如「权限控制」，可以设定每个账户的读写权限，而Git中
则没有响应的权限控制。至于用哪个的，还是看公司要求吧~

3. Git的四个组成部分

简单说下Git的四个组成部分：

• 工作区：不包含.git文件夹在内的整个项目目录，所有修改都在工作区内进行。
• 暂存区：又称索引区，本地文件修改后，执行add操作会把工作区的修改添加到缓存区。
• 本地仓库：当执行commit操作时，暂存区的数据被记录到本地仓库中。
• 远程仓库：托管项目代码的服务器，多人协作时通过远程仓库进行代码同合并与同步。

接下来说下这几个部分是如何协同工作的：

工作区与暂存区：工作区更改，通过git add命令可以把更改提交到暂存区；
也可以git checkout命令使用暂存区内容覆盖当前的工作区的内容。
 
暂存区与本地仓库：可以通过git commit命令把暂存区的内容提交到本地仓库，
每次commit都会生成一个快照，快照使用Hash值编号。可以通过git reset Hash值，
把某个快照还原到暂存区中。
 
工作区和本地仓库：通过git checkout 快照编号，直接把某个快照还原到工作区中。
 
本地仓库和远程仓库：可以通过git push命令把commit推送到远程仓库，多人协作的
时候可能还需要进行一些冲突处理；还有通过git clone拉取某个远程仓库的项目到本地，
或通过git fetch拉取远程仓库的最新内容，检查后决定是否合并到本地仓库中。
 
工作区和远程仓库：这里两者的协作一般是git pull，即把远程主机的最新内容拉取下来后直接合并。

4. Git中文件的几个状态

按照大类划分，可以分为两种状态：Tracked(已跟踪)和Untracked(未跟踪)，
依据是：「该文件是否已加入版本控制」？

文件状态变化周期流程图：

流程简述：

假设某个项目已加入Git版本控制系统

• 1.新建一个文件，该文件处于 Untracked 状态；
• 2.通过git add命令添加到缓存区，此时文件处于**Tracked状态又或者说
  此时这个文件已经被版本控制系统所跟踪，而且他处于Staged**(暂存)状态；
• 3.通过git commit命令把暂存区的文件提交提交到本地仓库，此时文件处于
  Unmodified(未修改)状态；
• 4.此时如果去编辑这个文件，文件又会变成**Modified**(修改)状态；

5. Git中的四类对象

在Git系统中有四种类型的对象，几乎所有的Git操作都是在这四种对象上进行的，依次为：
Blob（块）对象，Tree（树）对象，Commit（提交）对象，Tag（标签）对象。
前三者的关系如图所示：

接着我们来详解的讲解这四类对象：

① 块对象（Blob）

一块二进制数据，「仅存放文件内容」，不包括文件名、权限等信息。Git会根据文件内容计算
出一个Hash值，以这个Hash值作为文件索引保存起来。意味着，相同文件内容的文件，只会保存
一个，即共享同一个Blob对象。可以使用：git hash-object 文件名 来计算文件内容的Hash值。
如果你知道已经添加到Git中的某个文件的hash值，还可以通过 git cat-file hash值 来读取数据
对象，可选参数：-p（查看Git对象内容） ，-t（查看Git对象类型），示例如下：

② 树对象（Tree）

保存一个或多个块对象的引用，每次commit对应一个树对象，这里生成一个commit，
然后调用**git ls-tree Hash值** 查看树对象的内容：

利用上面的 git cat-file -p hash值 来查看blob块的具体内容：

除了保存块对象的引用外，树对象还可以引用「其他树对象」，从而构成一个「目录层次结构」。
新建一个test目录，复制一个1.txt文件到这个路径下，提交一个commit，然后查看树对象的内容：

可以指向了另一个tree对象，这个tree对象指向另一个1.txt文件，树对象解决了文件名的问题。
而对于提交的人、时间、说明信息等，我们还需要通过提交对象进行了解。

③ 提交对象（Commit）

保存树对象的Hash值，父Commit的Hash值，提交作者、时间、说明信息。
同样可以使用**git cat-file**命令查看commit对象：

④ 标签对象（Tag）

一般会对某次重要的commit加TAG，以示重要，分为两种情况：

• 轻量级标签：不会创建真正的TAG对象，而是直接引用commit对象的Hash值。
• 附加标签：会创建TAG对象，TAG对象中包含commit对象的引用，除此之外会创建
  一个文件：.git/refs/tags/标签名，里面保存TAG对象的引用。
  这里为我们上面的两个commit一次打上两种标签，然后看下具体的结果：
  

---

Git下载安装配置

---

• Windows系统：到 Git For Windows 或 git-for-windows.github.io下载，傻瓜式下一步。
• Linux系统：到 Download for Linux and Unix 下载，如果是Ubuntu的话，直接Terminal键入：
  sudo apt-get install git 安装即可。
• Mac系统：到 Installing on Mac 下载，不过新系统貌似默认已经带有Git了，另外如果安装了
  Homebrew的话可以直接命令行键入：brew install git 进行安装。

---

Git本地基本操作

---

1. 相关配置「git config」

安装完后，使用Git还需要进行环境的配置，配置信息保存在gitconfig文件中，有三种级别：

• system（系统）：系统中所有用户都会生效，配置文件：C:\Program Files\Git\mingw64\etc\gitconfig，
  不同的系统可能不一样，你可以通过：git config -e --system，底部可以找到配置文件的路径：
  
• global（全局）：当前系统用户下生效，配置文件：C:/Users/当前用户/.gitconfig，
  同样可以采用上面的：git config -e --global 查看配置文件的位置。
• local（本地）：配置仅在当前项目生效，配置文件：项目路径/.git/config

配置生效优先级：local > global > system，常用命令：

# 配置
git config --global user.name "用户名"          # 配置用户名
git config --global user.email "用户邮箱"       # 配置邮箱
git config --global core.editor 编辑器          # 配置编辑器，模式使用vi或者vim

# 查看配置
git config --global user.name       # 查看配置的用户名
git config --global user.email      # 查看配置的邮箱

# 查看所有配置列表
git config --global --list      # 查看全局设置相关参数列表
git config --local --list       # 查看本地设置相关参数列表
git config --system --list      # 查看系统配置参数列表
git config --list               # 查看所有Git的配置(全局+本地+系统)

除了命令行的方式外，你还可以直接去编辑对应的配置文件。

2. 获取帮助「git help」

git help 命令       # 查看某个git命令的介绍，用法
git 命令 --help     # 另一种写法

3. 创建本地仓库「git init」

git init 仓库名     # 创建一个新的带Git仓库的项目
git init           # 为已存在的项目生成一个Git仓库

4. 添加文件到暂存区「git add」

git add 文件名  # 将工作区的某个文件添加到暂存区。
git add -u     # 添加所有被tracked文件中被修改或删除的文件信息到暂存区，不处理untracked的文件
git add -A     # 添加所有被tracked文件中被修改或删除的文件信息到暂存区，包括untracked的文件
git add .      # 将当前工作区的所有文件都加入暂存区
git add -i     # 进入交互界面模式，按需添加文件到缓存区

很多人应该没用过交互界面模式，这里演示下用法：

流程简述：

• 在GitTest文件夹中新建两个文件；
• 键入git add -i，进入交互界面模式，键入4，选择添加untracked（未标记）的文件；
• 根据未标记文件的序号来添加文件，输入？会弹出相关提示，直接回车，结束选择；
• 键入4，可以看到已经不存在untracked的文件了。

5. 让Git不Tracked特定文件「.gitignore文件配置」

当我们使用git add命令把未标记的文件添加到缓存区后，Git就会开始跟踪这个文件。
对于一些比如：自动生成的文件，日志，临时编译文件，应用签名文件等，就没必要进行跟踪了，
我们可以编写一个**「.gitignore文件」，把不需要跟踪的文件和文件夹写上，git就不会去
跟踪这些文件了，另外：.gitignore文件与.git文件夹在同级目录下**。

如果不想自己写这个文件，可以到 https://github.com/github/gitignore 选择对应的模板，复制粘贴。
也可以自行编写，支持简化了的真这个表达式（规范与示例模板摘自：Git王者超神之路）

• * ： 匹配零个或多个任意字符
• [abc]：只匹配括号内中的任意一个字符
• [0-9]：- 代表范围，匹配0-9之间的任何字符
• ?：匹配任意一个字符
• **：匹配任意的中间目录，例如a/*/z可以匹配:a/z,a/b/z,a/b/c/z等

模板示例：

# 忽略所有以 .c结尾的文件
*.c

# 但是 stream.c 会被git追踪
!stream.c

# 只忽略当前文件夹下的TODO文件, 不包括其他文件夹下的TODO例如: subdir/TODO
/TODO

# 忽略所有在build文件夹下的文件
build/

# 忽略 doc/notes.txt, 但不包括多层下.txt例如: doc/server/arch.txt
doc/*.txt

# 忽略所有在doc目录下的.pdf文件
doc/**/*.pdf

有一点要特别注意！！！！

配置.gitignore只对那些没有添加到版本控制系统的文件生效(未Tracked的文件)！

举个简单的例子：

有A，B两个文件，你先把他两个add了，然后在.gitignore文件中
配置了不跟踪这两个文件，但是你会发现根本不会生效。

git add A
git add B
# 配置不跟踪A和B
git add .gitignore

所以，最好的做法就是在项目刚开始的时候，先添加.gitignore文件。
当然，即使是发生了，还是有解决方法的，可以键入下述命令清除标
记状态，然后先添加.gitignore，再添加文件即可：

git rm -r --cached .    # 清除版本控制标记，.代表所有文件，也可指定具体文件

另外，如果你用的IDEA系列的代码编辑器，可以安装一个「.ignore」的插件，手动
勾选不需要跟踪的文件，直接生成.gitignore文件。

6. 将暂存区的内容提交到本地仓库「git commit」

git commit -m "提交说明"    # 将暂存区内容提交到本地仓库
git commit -a -m "提交说明" # 跳过缓存区操作，直接把工作区内容提交到本地仓库

如果不加-m “提交说明”，git会让用你让默认编辑器(vi或vim)来编写提交说明。
除此之外，有时可能想修改上次提交的内容：提交说明，修改文件等：

# 合并暂存区和最近的一次commit，生成新的commit并替换掉老的。如果缓存区没内容，
# 利用amend可以修改上次commit的提交说明。
# 
# 注：因为amend后生成的commit是一个全新的commit，旧的会被删除，所以别在公共的
# commit上使用amend！切记！！！

git commit --amend 
git commit --amend --no-edit # 沿用上次commit的提交说明

7. 查看工作区与缓存区的状态「git status」

git status      # 查看工作区与暂存区的当前情况
git status -s   # 让结果以更简短的形式输出

8. 差异对比（内容变化）「git diff」

git diff                     # 工作区与缓存区的差异
git diff 分支名              # 工作区与某分支的差异，远程分支这样写：remotes/origin/分支名
git diff HEAD               # 工作区与HEAD指针指向的内容差异
git diff 提交id 文件路径     # 工作区某文件当前版本与历史版本的差异
git diff --stage           # 工作区文件与上次提交的差异(1.6 版本前用 --cached)
git diff 版本TAG           # 查看从某个版本后都改动内容
git diff 分支A 分支B       # 比较从分支A和分支B的差异(也支持比较两个TAG)
git diff 分支A...分支B    # 比较两分支在分开后各自的改动

# 注：如果只想统计哪些文件被改动，多少行被改动，可以添加--stat参数

9. 查看历史提交记录「git log」

git log                 # 查看所有commit记录(SHA-A校验和，作者名称，邮箱，提交时间，提交说明)
git log -p -次数                # 查看最近多少次的提交记录
git log --stat                  # 简略显示每次提交的内容更改
git log --name-only             # 仅显示已修改的文件清单
git log --name-status           # 显示新增，修改，删除的文件清单
git log --oneline               # 让提交记录以精简的一行输出
git log –graph –all --online    # 图形展示分支的合并历史
git log --author=作者           # 查询作者的提交记录(和grep同时使用要加一个--all--match参数)
git log --grep=过滤信息         # 列出提交信息中包含过滤信息的提交记录
git log -S查询内容              # 和--grep类似，S和查询内容间没有空格
git log fileName              # 查看某文件的修改记录，找背锅专用

除此之外，还可以通过 –pretty 对提交信息进行定制，比如：

更多规则与定制如下（更多可参见：Viewing the Commit History）
format对应的常用占位符：(注：作者是指最后一次修改文件的人，提交者是提交该文件的人)

占位符	说明	占位符	说明
%H	提交对象（commit）的完整哈希字串	%h	提交对象的简短哈希字串
%T	树对象（tree）的完整哈希字串	%t	树对象的简短哈希字串
%P	父对象（parent）的完整哈希字串	%p	父对象的简短哈希字串
%an	作者（author）的名字	%ae	作者的电子邮件地址
%ad	作者修订日期（可以用 –date= 选项定制格式）	%ar	按多久以前的方式显示
%cn	提交者(committer)的名字	%ce	提交者的电子邮件地址
%cd	提交日期	%cr	提交日期，按多久以前的方式显示
%s	提交说明

一些其他操作：

选项	说明
-p	按补丁格式显示每个更新之间的差异
–stat	显示每次更新的文件修改统计信息(行数)
–shortstat	只显示 –stat 中最后的行数修改添加移除统计
–name-only	仅在提交信息后显示已修改的文件清单
–name-status	显示新增、修改、删除的文件清单
–abbrev-commit	仅显示 SHA-1 的前几个字符，而非所有的 40 个字符
–relative-date	使用较短的相对时间显示（比如，“2 weeks ago”）
–graph	显示 ASCII 图形表示的分支合并历史
–pretty	格式定制，可选选项有：oneline，short，full，Fullerton和format(后跟指定格式)

还有一些限制log输出的选项：

选项	说明
-(n)	仅显示最近的 n 条提交
–since, –after	仅显示指定时间之后的提交。
–until, –before	仅显示指定时间之前的提交。
–author	仅显示指定作者相关的提交。
–committer	仅显示指定提交者相关的提交。
–grep	仅显示含指定关键字的提交
-S	仅显示添加或移除了某个关键字的提交

10. 查看某个文件是谁改动的「git blame」

git blame 文件名 # 查看某文件的每一行内容的作者，最新commit和提交时间

这里为了演示，先修改一波作者用户名和邮箱，然后往1.txt中新增内容：

Tip：如果你用的IDEA系列的编译器，右键行号，选择Annotate也可以实现同样的效果。如：

11. 设置Git命令别名「git config –global alias」

在终端使用Git命令的时候，虽然可以通过按两次tab来自动补全。但是有些命令比较常用，
每次都要敲完就显得有些繁琐了，可以为这些命令起一个简单的别名，比如：
status为st，checkout为co ; commit为ci ; branch为br等，设置示例如下：

git config --global alias.st status

别名的设置保存在git的配置文件中：

12. 为重要的提交打标签「git tag」

对于某些提交，我们可以为它打上Tag，表示这次提交很重要， 比如为一些正式发布大版本的
commit，打上TAG，当某个版本出问题了，通过TAG可以快速找到此次提交对应的Hash值，
直接切换到此次版本的代码去查找问题，比起一个个commit找省事多了。

Git中的标签分为两种：轻量级标签 和 附加标签，命令如下：

git tag 标记内容                    # 轻量级标签
git tag -a 标记内容 -m "附加信息"    # 附加标签

如果想为之前某次commit打TAG，可以找出此次提交的Hash值，添加-a选项，示例如下：

git tag -a 标记内容 版本id      # 比如：git tag -a v1.1 bcfed96

另外，git push 的时候默认不会把标签推送到远程仓库，如果想把标签页推送到远程仓库，可以：

git push origin 标记内容    # 推送某标签到远程仓库
git push origin --tags     # 删除所有本地仓库中不存在的TAG

除此之外还有下述常规操作：

git checkout -b 分支名 标记内容          # 新建分支的时候打上TAG
git show 标记内容                       # 查看标签对应的信息
git tag -d 标记内容                     # 删除本地TAG
git push origin --delete tag 标记内容   # 删除远程TAG

---

Git文件恢复与版本回退

---

1. 文件恢复（未commit）「git checkout」

如果在工作区直接删除已经被Git Tracked的文件，暂存区中还会存在此文件：

Git告诉你，工作区的文件被删除了，你有两种可选操作：「删除缓存区文件」 或 「恢复被删文件」：

# 删除暂存区中的文件：
git rm 文件名
git commit -m "提交说明"

# 误删恢复文件（用暂存区的文件覆盖工作区的文件）
git checkout -- 文件名

# Tip：git rm 等价于 git rm --cached 文件名 + rm 文件名
# 务必注意：git checkout会抛弃当前工作区的更改!!!不可恢复！！！务必小心！！！

2. 文件恢复（已add未commit）「git reset HEAD」

如果更改已经add到暂存区中，想恢复原状，可以执行下述命令：

git reset HEAD 文件名   
git checkout 文件名

3. 版本回退（已commit）【git reset –hard】

文件已经commit，想恢复未上次commit的版本或者上上次，可以：

git reset HEAD^             # 恢复成上次提交的版本
git reset HEAD^^            # 恢复成上上次提交的版本，就是多个^，以此类推或用
git reset HEAD~3            # 也可以直接~次数
git reset --hard 版本号      # git log查看到的Hash值，取前七位即可，根据版本号回退

reset命令的作用其实就是：重置HEAD指针，让其指向另一个commit，而这个动作可能会对
缓存区造成影响，举个例子：

本来的分支线：- A - B - C (HEAD, master)，git reset B后：- A - B (HEAD, master)
解释：看不到C了，但是他还是存在的，可以通过git reset C版本号找回，前提是
C没有被Git当做垃圾处理掉(一般是30天)。

reset提供了三个可选参数：

• soft：只是改变HEAD指针指向，缓存区和工作区不变；
• mixed：修改HEAD指针指向，暂存区内容丢失，工作区不变；
• hard：修改HEAD指针指向，暂存区内容丢失，工作区恢复以前状态；

4. 查看输入过的指令记录「git reflog」

Git会记住你输入的每个Git指令，比如上面的git reset 切换成一个旧的commit，然后
git log后发现新提交的记录没了，想切换回新的那次commit， 可以先调git reflog
获取新commit的Hash值，然后git reset 回去。

git reflog

注：指令记录不会永久保存！Git会定时清理用不到的对象！！！

5. 撤销某次提交「git revert」

有时可能我们想撤销某次提交所做的更改，可以使用revert命令

git revert HEAD             # 撤销最近的一个提交
git revert 提交的Hash值     # 撤销某次commit

注意！！！

不是真的把提交给撤销了，而是生成一个新的提交来覆盖旧的提交，被撤销的提交
和新的提交记录都会保存！！！如果不信的话，你可以再键入git revert HEAD，
会发现被撤销的更改又变回来了。简单点说：「撤销的只是文件变化，提交记录依旧存在」。

6. 查看某次提交的修改内容「git show」

git show 提交Hash值     # 查看某次commit的修改内容

7. 查看分支最新commit的Hash值「git rev-parse」

git rev-parse 分支名    # 查看分支最新commit的Hash值，也可以直接写HEAD

8. 找回丢失对象的最后一点希望「git fsck」

因为你的某次误操作导致commit丢失，如果git reflog都找不到，你可以使用git fsck，找到丢失
的对象的版本Hash值，然后恢复即可。

git fsck --lost-found

---

Git本地分支

---

1.分支的概念

分支并不是Git对象，和轻量级的TAG对象类似，只包含对commit对象的索引。只是分支更新后，
索引会替换为最新的commit，而TAG对象创建后索引就不在变化。分支文件保存与下述两个路径：

• 本地分支：当前项目/.git/refs/heads/
• 远程分支：当前项目/.git/refs/remotes/

说到分支，必然会提及HEAD，它指向「当前工作的本地分支」，对应文件：当前项目/.git/HEAD

下面通过示例和图解的方式帮大家理解分支：

如法炮制，提交两次：

从上面的图中不难发现这样的规律：每次commit，master都会向前移动，指向最新提交。
这个时候可能有些童鞋会问：commit之间的箭头哪来的？或者说commit怎么串成一条线的？

答：还记得一开始介绍的commit对象吗？里面有一个parent的值，指向父commit的Hash值。

2.创建其他分支的原因

通过两个常见的场景来体会创建其他分支的必要性：

• 场景一：

项目一般都是一步步迭代升级的，有大版本和小版本的更新： 大版本一般是改头换面的更新，比如
UI大改，架构大改，版本是： v2.0.0这样；小版本的更新一般是UI小改，Bug修复优化等，版本是：
v2.0.11这样；只有一条master分支，意味着：你的分支线会 非常非常的长，假如你已经发布到了
第二个大版本，然后用户反馈第一个版本有很严重的BUG，这时候想切回第一个版本改BUG，
然后改完BUG切回第二个大版本，想想也是够呛的。 (PS：可能你说我可以对重要的commit打tag，
然后找到这个tag 切回去，当然也行这里是想告诉你引入其他分支会给你带来的便利)

• 场景二：

如果只有一个master分支的话，假如某次commit冲突了，而这个冲突很难解决或者解决不了，
那么整个开发就卡在这里，无法继续向后进行了。

3.一个简单的分支管理策略

为了解决只有一个master分支引起的问题，可以引入分支管理，最简单的一种策略如下：

在master分支上开辟一个新的develop分支，然后我们根据功能或者业务，再在develop
分支上另外开辟其他分支，完成分支上的任务后，再将这个分支合并到develop分支上！
然后这个功能分支的任务也到此结束，可以删掉，而当发布正式版后，再把develop分支
合并到master分支上，并打上TAG。

master与develop分支都作为长期分支，而其他创建的分支作为临时性分支！
简述各个分支的划分：

• master分支：可直接用于产品发布的代码，就是正式版的代码

• develop分支：日常开发用的分支，团队中的人都在这个分支上进行开发
• 临时性分支：根据特定目的开辟的分支，包括功能(feature)分支，或者预发布(release)分支，
  又或者是修复bug （fixbug）分支，当完成目的后，把该分支合并到develop分支，
  然后删除该分支，使得仓库中的常用分支始终只有：master和develop两个长期分支！

4.分支创建与切换「git branch」

git branch 分支名   # 创建分支
git branch          # 查看本地分支

我们在master分支上创建一个develop分支，此时的版本线变成了这样：

此时虽然已经创建了develop分支，但是HEAD还是指向master，接着我们来切换分支：

git checkout 分支名         # 切换分支
git checkout -b 分支名      # 创建分支同时切换到这个分支

切换到develop后，提交一次，此时的版本线：

再提交一次，然后切换为master分支，此时的版本线：

切换回master后，提交一次，此时的版本线：

行吧，讲到这里，相信各位童鞋对Git中的分支已经有所了解了。

5.分支合并「git merge」 VS 「git rebase」

Git中，可以使用「git merge」和「git rebase」两个命令来进行分支的合并。

git merge合并分支

合并的方式分为两种：快速合并 和 普通合并，两者的区别在于：
「前者合并后看不出曾经做过合并，而后合并后的历史会有分支记录」
如图所示：

快速合并，默认，快速合并有一个前提：「当前分支的每个提交都在另一个分支中」，
Git不创建任何新的commit，只是将当前分支指向合并进来的分支。下面演示下快速合并，
执行git reset 切换到第四次commit，然后执行git merge develop合并master分支。

普通合并，添加**–no-ff**参数表示禁用快速合并。

另外有时会有这样的场景：合并的分支中有很多commit记录是无需在分支中体现的，一个commit
就够了。可以借助**–squash**参数来压缩提交，示例如下：

附：git merge的常用参数：

git merge -ff           # 快速合并，默认参数
git merge -ff-only      # 只有快速合并的情况才合并
git merge --no-ff       # 不使用快速合并
git merge -n 分支名     # 合并分支，不会在合并后显示合并前后的不同状态
git merge -stat 分支名  # 合并分支，合并结束后显示合并前后的不同状态
git merge -e 分支名     # 合并分支，合并前调用编辑器，可自行编写commit

Tips: git-merge除了用来合并分支外，拉取远程仓库更新时也可用到（git fetch + git merge）

git reabse合并分支

rebase（衍合，变基），网上很多教程写得很高深莫测，其实并没有那么复杂，
只是这种合并会让树整洁，易于跟踪。以上面4中的结果为例，先把master分支
和develop分支重置到最新的commit。

先走一波前面的merge合并方式：

接着再试试rebase合并方式：

Git会把每个提交都取消掉，并把他们临时保存为补丁，比如经过一些冲突解决，生成新的commit，
旧的commit会被丢弃，还会被git的gc回收，这样的结果就是一条直线的树。

6.解决合并冲突

在分支的合并的时候，并不是每次都能直接合并的，有时会遇到合并冲突，特别是在多人协作的时候。
出现合并冲突后，需要解决完冲突，才能继续合并。

举个简单的例子，A和B在master分支上开辟出两个分支来完成相关的功能，
A做完了，把自己的分支合并到master分支，此时master分支向前移动了几次commit，
接着B也完成了他的功能，想把自己分支合并到master分支，如果改动的文件和和A改动
的文件相同的话，此时就会合并失败，然后需要处理完冲突，才能够继续合并！

接下来我们来简单的模拟合并冲突，先来试试merge：

merge分支后处理冲突

如图，合并完A分支后合并B分支出现了冲突，接着键入：git status查看冲突的文件：

可以看到未合并的两个文件，1.txt和2.txt，打开其中一个文件：

<<< 和 >>>包裹着的就是冲突内容，保留自己想要的内容，处理完后删掉<<<和>>>，修改完后：

2.txt文件也如法炮制，接着add，然后commit即可，合并结束。

rebase分支后处理冲突

如图，A合并成功，在合并B的时候，出现了合并冲突，有三个可选的操作：

git rebase --continue # 处理完冲突后，继续处理下一个补丁
git rebase --abort # 放弃所有的冲突处理，恢复rebase前的情况
git rebase --skip # 跳过当前的补丁，处理下一个补丁，不建议使用，补丁部分的commit会丢失！

键入git status查看冲突文件：

接着处理1.txt文件中的冲突，解决完成后，先键入git add，接着键入git rebase --continue
处理下一个冲突：

处理接下来的冲突，直到没有冲突为止：

可以看到使用rebase合并，最后的分支线是一条直线。另外，使用rebase合并中途出差错，
可以使用git rebase --abort恢复rebase前的状态。

7.删除分支

合并完的分支，基本没什么用了，可以使用下述命令删除：

git branch -d 分支名    # 删除分支，分支上有未提交更改是不能删除的
git branch -D 分支名    # 强行删除分支，尽管这个分支上有未提交的更改

8.恢复误删分支

两步：找出被删分支最新的commit的Hash值，然后恢复分支：

git log --branches="被删除的分支名"     # 找到被删分支最新的commit版本号
git branch 分支名 版本号(前七位即可)    # 恢复被删分支

9.切换分支时暂存未commit的更改「git stash」

有时我们可能在某个分支上正编写着代码，然后有一些突发的情况，需要 我们暂时切换到
其他分支上，比如要紧急修复bug，或者切换分支给同事 review代码，此时如果直接切换
分支是会提示切换失败的，因为这个分支 上做的更改还没有提交，你可以直接add后commit，
然后再切换，不过我们习惯写完某个功能再提交，我们想：

先暂存这个分支上的改动，切去其他分支上搞完事，然后回来继续
继续在之前的改动上写代码。

那么可以使用：

git stash   # 保存当前的改动

然后放心的切换分支，然后再切换回来，接着使用：

git stash apply     # 恢复保存改动

另外有一点一定要注意！！！可以stash多个改动！！如果你切换到另一个分支
又stash了，然后切换回来stash apply是恢复成另一个分支的stash！！！
如果你这样stash了多次的话，我建议你先键入：

git stash list      # 查看stash列表

找到自己想恢复的那个

比如这里恢复的应该是master上的stash，可以使用下述命令进行恢复：

git stash apply stash@{1}

10.分支重命名

git branch -m 老分支名 新分支名     # 分支重命名

11.把提交的commit从一个分支放到另一个分支「git cherry-pick」

有时我们可能需要把某个分支上的一次commit放到另一个分支上，此时可以使用git cherry-pick，
比如下面这样两个分支：

master分支：A -> B -> C
feature分支：a -> b

现在想把feature分支上的b，放到master的后，可以这样操作：

• Step 1：切换到feature分支上，git log拿到b commit的版本号(SHA1)。
• Step 2：切换到master分支，键入：git cherry-pick 版本号。

---

PS：文章后续还会调整…有疑问的地方欢迎在评论区提出，谢谢~

---

参考文献与更多Git学习资料：

• Pro Git 中文版
• Git背后的object

---

如果本文对你有所帮助，欢迎
留言，点赞，转发
素质三连，谢谢~

---

---