1、git commit
Git 仓库中的提交记录保存的是你的目录下所有文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！
Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。
Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有 parent 节点的原因 。
git commit提交以及就会建立一个新的节点。
初始提交
C0
和其后可能包含某些有用修改的提交
C1，再次git commit就会产生一个新的节点C2。
2、git branch
是简单地指向某个提交纪录.
创建一个到名为
newImage
的分支，新创建的分支
newImage
指向的是提交记录
C1
$ git branch newImage
往新分支里提交一些东西,会有如下结果：
$ git commit
为什么
main
分支前进了，但
newImage
分支还待在原地呢？！这是因为我们没有“在”这个新分支上。
看到
main
分支上的那个星号（*）了吗？这表示当前所在的分支是
main
。
现在切换到新的分支上
$ git checkout newImage
$ git commit
我们的修改已经保存到新的分支里了。（注意星号( * ) 的位置）
注意：在 Git 2.23 版本中，引入了一个名为
git switch的新命令，会取代
git checkout，因为
checkout作为单个命令有点超载（它承载了很多独立的功能）。
3、git merge
接下来,如何将两个分支合并到一起? 就是说我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线
在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个 parent 节点。
准备两个分支，每个分支上各有一个独有的提交。这意味着没有一个分支包含了我们修改的所有内容。通过合并这两个分支来确认我们修改的所有内容。
把
bugFix
合并到
main
里(指令中输入bugFix，默认将其合并到main)
$ git merge bugFix
变成：
首先，
main
现在指向了一个拥有两个 parent 节点的提交记录。假如从
main
开始沿着箭头向上看，在到达起点的路上会经过所有的提交记录。这意味着
main
包含了对代码库的所有修改。
看见各个提交记录的颜色变化了吗？为了帮助学习理解，引入了颜色搭配。每个分支都有不同的颜色，而每个提交记录的颜色是所有包含该提交记录的分支的颜色混合之后的颜色。
所以，
main
分支的颜色被混入到所有的提交记录，但
bugFix
没有。下面让它也改变一下颜色。
把
main
分支合并到
bugFix
：
$ git checkout bugFix
$ git merge main
→ 
→
因为
main
继承自
bugFix
，只是简单地把
bugFix
移动到
main
所指向的那个提交记录。
4、git rebase
第二种合并分支的方法是
git rebase
。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。
Rebase 的优势就是可以创造更线性的提交历史。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。
准备两个分支；注意当前所在的分支是 bugFix。
我们想要把 bugFix 分支里的工作直接移到 main 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。
$ git rebase main # 当前分支在 bugFix
→ 
现在 bugFix 分支上的工作在 main 的最顶端，同时我们也得到了一个更线性的提交序列。
注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 Rebase 到 main 分支上的 C3 的副本。
现在唯一的问题就是 main 还没有更新，现在更新：
$ git rebase bugFix
→ 
由于
bugFix
继承自
main
，所以 Git 只是简单的把
main
分支的引用向前移动了一下而已。
版权归原作者 丶七年先生 所有， 如有侵权，请联系我们删除。