本文为学习笔记，并非原创。原文链接，原文发表于2020-11-15

本篇文章写得真的不错，建议全文阅读。这里只记我不熟悉的地方。

commit节点、HEAD和分支

每次commit都会生成一个节点，节点内容是本次及本次之前所有提交的内容。

不管HEAD还是分支，都是对一个commit节点的引用。因为只是引用，所以它们非常轻量。引用+节点是git构成分布式的关键。

HEAD是一个引用，它可以指向任意一个节点。其指向的节点始终为当前工作目录，换句话说就是当前工作目录（也就是你看到的代码）就是HEAD指向的节点

分支也可以视为一个引用，分支指向一个节点时，该节点的内容就是分支的内容。

分支可以存在多个，而HEAD只有一个。

合并

merge

git merge 分支名/节点哈希值   //将指定分支或节点的内容合并至HEAD

如果要合并的内容完全领先于当前分支，如下图中在ft-2上执行git merge ft-1，则会触发fast-foward（快速合并），此时两个分支指向统一节点。

但实际情况中，往往遇到的是下图中的情况。这种就不能直接合并了，在ft-2上执行git merge ft-1，会将节点C3、C4直接合并后生成一个C5节点，最后将ft-2指向C5。

注意：如果C3和C4修改了同一个文件的同一行，这个时候合并会出错，git并不知道以谁为准，需要自己手动合并代码。

rebase

git rebase 分支名/节点哈希值

rebase看起来不会产生新的节点，但实际上是将节点复制为一个新的节点，如下图：

上图左边的ft-1分支上执行git merge master后，会将C4节点复制一份到C3后面，也就是C4'。C4'与C4相对应，但是哈希值并不一样。

rebase相比于merge，提交历史更加线性、干净，使并行的开发流程看起来像串行，更符合我们的直觉。

merge和rebase的优缺点

merge优缺点

• 优点：每个节点都是严格按照时间排列。当合并发生冲突时，只需要解决两个分支所指向的节点的冲突即可。
• 缺点：合并两个分支时，大概率会生成新的节点并分叉，久而久之提交历史会变成乱麻。

rebase优缺点

• 优点：会使提交历史看起来线性、干净

• 缺点：虽然提交看起来是线性的，但不是真的按时间顺序。当合并发生冲突时，有几个节点rebase到当前分支，就有可能要处理几次冲突。

cherry-pick

假设当前分支是master，执行了git cherry-pick C3(哈希值)，C4(哈希值)命令后会直接将C3、C4节点抓过来放在后面，对应C3'和C4'