深刻理解Git - 一切皆commit

时间 2019-11-20 标签深刻理解 git 一切 commit

在对 git 有了基本理解和知道常规操做以后，如何对 git 的使用有进一步的理解？
一切皆 commit 或许是个不错的理解思路。html

本文将从『一切皆 commit 』的角度，经过 git 中常见的名词，如 commit, branch, tag, HEAD 和动词，如 cherry-pick, rebase, reset, revert, stash 来理解 git。经过这些理解，指望可以更好地处理使用 git 中遇到的问题。git

好比：shell

1 作了两个提交的修改，而后删掉分支了，过会发现刚才两个提交有价值，怎么找回来？
2 基于当前 release 分支开发功能，中途误合并了 dev 分支，
而后又进行了几回提交，怎么取消合并dev的操做？
3 rebase(变基)到底是什么意思？
等等。

配合希沃白板课件食用，效果更佳：
【希沃白板5】课件分享 : 《Git 进阶 - 从使用角度深刻理解Git》
https://r302.cc/ke8XdO?platform=enpc&channel=copylink
点击连接直接预览课件fetch

一切皆 commit

1 commit 的原子性

在 git 中有工做区，暂存区和代码仓库三个概念，那为何要有暂存区呢？为了保证提交的原子性，在 git 的应用层面上，提交（commit，名词）是 git 主要命令的操做的最小单位了。翻译

关于此，能够查看这篇知乎贴：为何要先 git add 才能 git commit ？ - Ivony的回答 - 知乎指针

本文中的内容不多涉及工做区和暂存区的操做，有了 commit 是 git 操做的基本单位这个概念，接下来将从『一切皆 commit』来理解 git。code

2 一切皆 commit ：名词部分

2.1 本地仓库

如上图，其实比较好理解，咱们知道 commit 有一个 commit id，另外仍是 branch（分支），tag（标签），HEAD（当前分支头结点）这些概念。他们都是指向某个提交的引用（或者理解为指针）。orm

branch（分支）：指向你当前工做分支的最新的那个提交，当在当前分支有了新的提交，则 git 自动更新这个分支指针，以指向最新的提交。
tag（标签）：对某个提交或者分支打 tag 以后，将固定指向那个提交，后续即便分支有更新甚至删除，tag 所指向的提交不变，且一直存在。
HEAD（头结点）：指向当前工做的分支，即 HEAD 是当前分支的一个引用，若是切换了分支，HEAD 随之更新。

如此，便理解了，branch，tag，HEAD 这些，本质上都是指向某个提交的引用，即：一切都是 commit 。htm

2.2 远端仓库

有一个引用，须要单独说明，就是 origin/branch ，一般称之为远程分支，那这个远程分支指向哪里呢？
如何在『一切皆commit』这句咒语下理解远程仓库？对象

以 master 分支为例，origin/master 指向的，就是当前远端 master 分支最新的那个提交。等等，其实这句话有点小问题，应该是最后一次更新本地仓库时，远端 master 分支最新的那个提交。那何时会更新远程仓库？在执行 pull push fetch 时更新。

你或许据说过 git pull = git fetch + git merge 的说法。
当执行 git fetch 命令时，只更新 origin/master 分支（包括全部其它的 origin 远端分支），但并不会影响本地的任何分支。

那要更新本地的 master 分支怎么办？ git merge origin/master ，将远端的分支合并到本地分支，即完成了对本地 master 分支的更新。因此，实际上，git pull = git fetch + git merge 。
(@master)git pull = git fetch & git merge origin/master

案例

你在 f/table 分支开发功能，如今须要合并最新dev，能够怎么作？

刚学 git 时，可能会这么作：

(@f/table) git checkout dev
(@dev) git pull 
(@dev) git checkout f/table
(@f/table) git merge dev

实际上，不须要切到 dev 分支，先更新 dev，则合并。如下命令便可：

(@f/table) git fetch
(@f/table) git merge origin/dev

小结：origin/branch 是指向此分支云端最新提交的引用（最新=最后一次更新），在执行 fetch pull push 指令时自动更新。

可使用 git show 命令查看一个提交的详细信息，
由于 commitId/HEAD/branch/tag/origin-branch 这些都是指向一个提交，因此 show 命令后面写任意一个均可以。
另外，还可使用其余参数控制显示内容，这里不展开。

git show commitId/HEAD/branch/tag/origin-branch --format=short

3 一切皆 commit ：动词部分

3.1 cherry-pick

cherry-pick 比较好理解，就是将一个指定提交的修改摘取过来，举例：

如图，6 提交是增长一个有用的 helper 类（间接说明，一个 commit 最好功能独立），但你不想将整个分支合并过来，就可使用 cherry-pick 命令。使用任何一个指向 6 提交的引用均可以。
须要说明的是，cherry-pick 过来的提交，只是内容与以前的提交同样，他们是两个不一样的提交。

案例

作了两个提交的修改，而后删掉分支了，过会发现刚才两个提交有价值，怎么找回来？

Step1 使用 git reflog 查看以前的提交历史，找到须要找回的提交ID。

Step2 使用 cherry-pick 命令将须要的提交摘取出来便可。

如何丢失的提交比较多，除了能够批量 cherry-pick 以外，根据实际状况，能够直接在那些提交的最新提交上，新建一个分支，那些提交在此以前的全部提交，都在新的分支上了。

新建分支(03620f1 指提交号/commit id)：

git branch newbranch 03620f1
git checkout -b newbranch 03620f1

3.2 rebase

若是用一句话理解 rebase 的话，就是：rebase = 一连串自动的 cherry-pick 。

关于 rebase ，须要回答三个问题：

为何推荐使用 rebase 而不是 merge？
为何据说过使用 rebase 会被打？
使用 rebase 有什么问题(什么状况不用 rebase )？

rebase 到底是什么意思？

如上图，假设 dev 上的提交是 1-2-3-4-5，f/table 分支上的提交是 1-2-3-6-7。如今咱们须要合并 dev，一般，会使用 (@f/table)git merge dev 的方式合并。这里，咱们使用 rebase 来合并 dev 。

首先，rebase 会找到 dev 和 f/table 共同的父提交，即 3 提交。而后以 dev 最新的提交为基础，把 f/table 分支上新的提交（这里就是 6 和 7），逐个 cherry-pick 过来。造成新的 f/table 分支。

注意，整个过程当中，对 dev 分支不会有任何影响，由于你是在 f/table 上进行的操做。全部，rebase 的中文翻译，变基，就能够理解为：变基：用 cherry-pick 的方式，给 f/table 上的新提交，换一个基，将基从以前的 3 换到了 dev 所指的提交 5 上。

问题1 为何推荐使用 rebase 而不是 merge？

当使用 merge 时，提交历史如右侧所示，使用 rebase 的提交历史以下侧所示。
提交历史更清晰，当分支很是多时，回溯提交与查找问题更容易。

问题2 为何据说过使用 rebase 会被打

使用 rebase 会修改提交历史，上面的例子中，6和7提交将不在 f/table 分支上存在，取而代之的是8和9分支，在协做分支上，若是6和7已经存在于远端仓库（即别人可能已经基于此有了新的修改），再将6和7移除，将带来诸多冲突与合并的麻烦。（这是，你 push 时，也须要强推，在协做分支上强推，是很危险的行为。）
因此：rebase只对本地未推送的commit上或本身的分支上进行。

问题3 使用 rebase 有什么问题(什么状况不用 rebase )

使用 rebase 的收益：更简洁清晰易回溯的提交历史。

使用 rebase 的代价：逐个 cherry-pick ，若是有冲突，须要逐个解冲突，使合并变复杂。

以合并 dev 分支为例，当工做分支已经作了大量修改（有不少提交，预期有许多冲突），或者以前 merge 过 dev。则建议使用 merge 的方式合并 dev。

rebase 小结：
rebase : 一连串的 cherry-pick。（移花接木）

3.3 reset

reset，重置，将当前分支的状态（这里指工做区，暂存区，代码仓库）重置到指定的状态。reset 的语法以下图，第一个参数是重置方式，后面是一个指向提交的引用（能够是提交ID，分支，tag，HEAD~1等等）。

与 rebase 同样，reset 只对当前分支和工做区，暂存区的数据有影响，对参数中指定的引用没有影响。即 (@f/table)git reset --hard dev 这句命令，影响的是 f/table 分支，对 dev 没有任何影响。

具体来看：

git reset --hard

从参数名能够猜到，这个重置方式比较“强硬”，实际上就是，将当前分支，重置到与指定引用同样的状态，丢弃在这以后的提交，以及工做区和暂存区的提交。

未追踪的文件是不受影响的，PS：git clean 命令会清除掉未追踪的文件。

案例1

(@f/table)git reset --hard f/table~2 的含义？

当前在 f/table 分支，将其重置到 f/table~2 ，结果就是：丢弃掉 f/table 最新的两个提交。

案例2

将当前分支重置到远端最新 dev 的状态，怎么作？

(@f/table)git fetch
(@f/table)git reset --hard origin/dev
注意，这里须要先 fetch 一下远程仓库，更新 origin/dev 分支。

git reset --soft / --mixed

理解了 --hard 的含义，--soft 和 --mixed 就很好理解了，这两个参数，不会丢弃任何内容。

--soft 会将指定提交以后的提交内容，都放到暂存区，同理，--mixed 会将指定提交以后的提交内容，以及暂存区中的内容，放到工做区。

因此，git reset --mixed HEAD (能够简写为 git reset)，实现的效果就是：将暂存区中的内容，回退到工做区。
git reset --hard HEAD (能够简写为 git reset --hard)，实现的效果就是：将工做区和暂存区中的所有内容。

案例1 将图中的 2 3 4合并为一个提交

案例2 移除误合并

3.4 revert

reset 用于修改错误，一般会修改提交历史，
这在团队协做分支上是危险且不容许的（如不少仓库的 master 分支）。
这时可使用 revert 命令。

revert 很好理解，就是新建一个提交，用于撤销以前的修改。

有个问题，revert 一个 merge 提交会怎么样？

如图，若是执行 (@f/table)git revert 6
会获得相似这样的提示：

这时，使用 -m 参数能够指定保留那边的提交，可选内容只有 1 和 2 （对于一般的两两合并的状况而言），
1 指代当前分支的那些提交，若是不是很肯定，可使用 git show 命令查看那个合并提交，在前的那个父节点为 1 。

留两个思考题：
1 如何在一切皆 commit 的语境下理解 git commit --amend
2 如何在一切皆 commit 的语境下理解 git stash

后篇：
深刻理解Git - Git底层对象

原文连接: http://www.javashuo.com/article/p-zzlopvae-kq.html

END