浅谈Git

Git是Linus Torvalds为了帮助管理 Linux内核开发而开发的一个开放源码的版本控制软件。采用了分布式版本库的方式，不必服务器端软件支持。

1. 工作区：未被Git管理的区域，在此区域的任何操作在Git add之前都与Git无关。也可以用Git rm使得文件脱离Git的管理。
2. 暂存区：存放已经被Git纳入管理，但是未被归结为提交记录的改动。直接对接工作区。
3. 分支：Git中最重要的概念，所有的提交记录都在分支上。借助分支，Git可以实现多个功能的并行开发，或者大型开发团队的同步工作。
   下面介绍Git的命令：

Git Commit

Git Commit是Git最为常用的指令，用于将已经加入暂存区的改动归结为一个新的“节点”（提交记录）。

如上图，使用git commit之后产生了新的节点C2，并且修改了当前分支和HEAD所指向的位置。

Git Branch

Git Branch用于产生一个新的分支，注意是从当前分支所指向的提交记录产生，分支之间完全隔离。在一个分支上Commit产生的新节点完全不会影响另一个分支。

如上图，在一个分支上Commit后产生的新节点从属于该分支，同时HEAD的位置会在分支上移动，但其他分支指向的节点不受影响。

Git Checkout

Checkout大体可以分为两种用法，其一为Git Checkout <分支名>，这会在分支之间移动，也会改变HEAD的位置。移动后，可以看到的暂存区代码也会相应改变为移动后分支所指的节点代码，但工作区的代码改动不受影响。
其二为Git Checkout <提交记录>，这一操作会使HEAD单独移动至所选提交记录。
至此，应该解释一下HEAD的含义了。HEAD独立于分支，指向目前工作区所关联的节点。一般情况下，HEAD都会指向当前分支的最新节点。但是Checkout命令可以单独改变HEAD的位置，使其不再指向任何分支的最新节点。可以使用cat .git/HEAD查看HEAD的位置。
借助HEAD，我们可以不使用节点们的SHA-1哈希值，而是使用他们和HEAD或分支指向的相对位置进行HEAD的移动，有两种方法：

1. Git Checkout <分支名/HEAD>^
   移动到分支指向节点/HEAD指向节点的父节点。
2. Git Checkout <分支名/HEAD>~<数字>
   移动到分支指向节点/HEAD指向节点的<数字>代祖宗节点。
   这种方法称为相对引用。借助它，我们可以强制修改分支所指向的位置，借助Git Branch -f <分支名> <节点>，这条命令中的节点可以是哈希值，也可以用相对引用标定。
   

如上图，我们在没有切换到main分支上的情况下，就改变了main分支所指的位置。

Git Merge

Git Merge命令会产生一个新的节点，作为所Merge两个分支的共同后继节点。Merge后，主动发起Merge的分支会指向新节点，参与Merge的分支指向不变，但他在已有Merge产生的子节点的情况下，主动发起Merge后也会指向子节点。

Git Rebase

Git Rebase命令同样用于合并两个分支，但不会产生新的节点，而是将两个分支的节点“梳理”到一个分支上。

如上图，主动发起Rebase的分支会将自己独有的节点嫁接到目标分支上，并转移自己所指的节点，从而将目标分支改造成了一条线性包含对方所有节点和自己节点的分支。同样，对方分支主动发起Rebase后会指向共有分支的子节点。
借助Git Rebase -i命令，可以拉起一个交互式窗口，实现对某一个分支的提交记录排序，或者舍弃某些节点。

Git Revert

Git Revert可以产生一个新的节点，这个节点可以看作所选发起Revert的镜像，撤销该节点的全部修改。

Git Reset

Git Reset会同时移动当前分支和HEAD的指向到目标节点，可以比喻为在目标节点处剪枝，之后的所有提交记录都变成了工作区中没加入的暂存区的改动。

Git Cherry-Pick

语法为git cherry-pick <提交记录>，将目标提交记录复制到HEAD下面。

如上图，执行git cherry pick C2 C4后，一次性将所选的两个节点全部添加到了本分支上，且将本分支和HEAD都移到了叶子节点。