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

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

• 看到掘金的童鞋发了好几条小册的票圈，想想自己第一本入的小册是凯哥的： Git 原理详解及实用指南 ， 和很多童鞋一样，买了就当自己学了（看都没看过），写总结的的时候顺带看下咯。
• 之前也写过一篇Git总结的文章，投掘金的处男稿，惨被拒，写Git有种承前启后的赶脚。
• 很多用Git的童鞋还停留在git pull和push等基本操作的程度。

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

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

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

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

1. 什么是版本管理系统

Version Control System，简称VCS，一种用于记录一个或多个文件内容变化 历史，以便将来能对特定版本的历史记录进行查看，更改，备份还原的系统。

可以类比成「 游戏存档 」，特定时间结点：比如打Boss前存档，如果GG了，重新 读档就好了；还比如分支剧情，想体验不同选择触发的不同的剧情，存多个档，想玩 哪个档读哪个档。

VCS一般分为以下三类：

• 1. 本地VCS

• 2. 集中式VCS

• 3. 分布式VCS

2. Git与SVN的区别

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文件夹在同级目录下**。

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

*
[abc]
[0-9]
?
**

模板示例：

# 忽略所有以 .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