Git入门与理解

简介

Wiki：

Git is a distributed version-control system for tracking changes in source code during software development.

Git 是一个常见的版本控制工具，在软件开发中普遍使用，也用来分工协作。

此文章适用于对Git有所了解，但~~（多次）~~ 希望入门 Git 却一直无法入门的人 ~~（比如我）~~，主要从理解上解决不知道为什么就不能切换分支，不能merge，不能push等等问题。此外，文章不对命令的各种参数进行详细介绍（需要翻翻手册就好啦~

推荐阅读（可以先把他们过一遍，可能就不用看这篇了：）

常用 Git 命令清单作者：阮一峰

Learn Git Branching 关卡式的有趣教程，对 Git 的分支与版本有一个形象的展示，了解命令之间的不同

启动了Git的文件夹中包括三个空间：**工作区 [Workspace]，暂存区 [Index / Stage]，本地仓库 [Repository]**。三个空间相互独立，通过 Git 命令进行文件在不同区之间的转化控制。

工作区即直接打开文件的地方。对文件的修改均在工作区中进行。通过将工作区的文件添加到区域从而产生备份[历史]。而可以根据暂存区或本地仓库中重置工作区的文件从而实现版本控制的效果 [即回退]。

此外，Git 的主要功能还有远程协作，因此还有一个**远程仓库 [Remote]**。

图源：常用 Git 命令清单 [侵删]

下面根据 暂存区 [Index / Stage]，本地仓库 [Repository]，远程仓库 [Remote] 的主要操作进行介绍。

暂存区

和暂存区相关的主要操作即为 git add, git commit以及撤销回退操作。

如上图所示，git add将修改提交到暂存区后，git commit将暂存区中的修改提交到本地仓库。

为什么需要有暂存区？知乎有一个问题：《为什么要先 git add 才能 git commit ？》而我个人的理解是，暂存区是本地仓库之前的一个暂时备份。在一些情况下，我们希望可以保存当前的修改，若之后的修改不满意可以回退，又认为当前的修改还不够完善，不应该作为一次版本提交，此时可以使用暂存区暂存。

需要注意的是，暂存区和工作区是基于一个 commit 存在的。在当前的 commit 与暂存区或工作区中的内容不同时，无法切换到其他的 commit。为什么这里说的是 commit 而不是分支呢？因为分支实际上是通过指针实现的。当两个分支指向同一个 commit 时，可以带着当前的暂存区和工作区切换分支。

下面通过图解介绍一些常用的命令：

提交命令

首先，我们通过 git init 初始化 git，然后新建了a.txt 文件，并写入 “Test 1”，此时状态为：

命令 git add .之后：

命令 git commit -m "a"之后：

可以简单知道， git add .将修改从工作区放入暂存区，git commit -m "a"将修改从暂存区放入本地仓库。

下面测试一些函数：我们在 a.txt 文件中添加 “Test 2”，执行 git add .，再在 a.txt 文件中添加 “Test 3”，此时的状态为：

查看命令

使用命令 git status: 可以看到，有修改需要commit，也有修改需要 add

命令 git diff: 显示了暂存区与工作区的区别

命令 git diff HEAD: 显示了工作区与当前的 commit 的区别 [HEAD 表示的是当前所在的commit]

撤销命令

命令 git checkout .：恢复暂存区的所有文件到工作区（当然也可以只恢复一个文件

命令 git reset ：重置暂存区的指定文件，与上一次commit保持一致，但工作区不变。注意现在直接看文件时看不到重置的，因为看的是工作区的内容。也可以同时修改暂存区和工作区[–hard]。

到这里暂存区的概念大概就懂了：）~~剩下的就是背命令了~~

切换分支

接下来是第一个坑：无法切换分支。更准确的说法是：当工作区或暂存区有修改时，无法切换 commit。

继续我们的实验：此时，新建并切换到一个新的分支 git checkout -b other 。这里是可以成功的：我们并没有切换 commit ，而是多了一个指向当前 commit 的指针：other。暂存区和工作区的内容也没有改变。

通过 git add .和git commit -m "a" 新建一个提交后，Master 和 other 分支会指向不同的 commit ：

接着修改 a.txt，尝试切换为 master 分支，失败：因为需要切换 commit

通过 git add .和git commit -m "a"将修改提交。可以顺利切换到 master 分支。此时执行 merge 操作：git merge other 由于 master 分支指向的 commit 的是 other 分支所指向的 commit 父节点，因此 merge 操作简单的将 master 分支的指针移动到 other 分支所指向的 commit 父节点。也就是说：他们又指向了同一个 commit 。此时即使修改工作区或暂存区的内容，也可以直接切换到 other 分支。[关于 merge ，下面会说到]

当暂存区有修改又希望切换分支时，可以使用 git stash 系列命令，将当前的工作隐藏起来，这里不展开。

关于暂存区暂时就到这，接下来是更奇怪的本地仓库

本地仓库

本地仓库中的版本是根据 commit 存储的，而不是根据分支。事实上，大多数命令中出现分支的名字都是用于指定一个 commit，可以用其他指定 commit 的方法替代。指定 commit 的方法有很多：

分支：最常用的显然是分支的名称。分支表示的是一个指向 commit 的指针，分支很容易被人为移动，并且当有新的提交时，它也会移动。因此，分支很容易被改变。
标签：由于分支容易改变，有时候我们希望可以给一次commit 打上永久的标识，这就是标签，用 git tag 等命令可以创建和查看、删除标签。
相对位置：可以在一个指定的 commit 后添加符号表示相对它的位置。有两个表示相对位置的符号 ‘^’, ‘~~‘。其中，’~~‘ 表示父节点，后面可以加数字表示往上寻找的第几个父节点，比如 ‘~2’ 表示爷爷节点。’^’也表示父节点，后面加数字表示多个父节点中的第几个父亲，如在 merge 后，’^2’ 表示不是原本分支的另一个分支（我也不知道还有什么情况有多个父节点）。在使用相对位置时， head 表示当前所在的 commit 。
commit 序号：每创建一个commit ，Git都会自动生成一个唯一的序号指定这个commit。不过 Git自动生成的序号都是一段很长的编码，难以记录。如果一定要使用，只需要用前几个字符即可代表一个commit

下面的图解用 Learn Git Branching 提供的沙盒生成，解释参考该教程，侵删。图解中，一个圆点表示一个commit

合并分支

合并分支 (commit) 主要有两种方式：merge，rebase

Git merge

merge合并两个分支时会产生一个新的提交记录，它有两个父节点。当merge的分支是当前分支的子节点时，只是简单的移动当前分支。

还是实例：在 master 分支下git merge other ，会形成图二的 commit [HEAD^ 表示的是 C3 这个commit，HEAD^2 表示的是C2]。切换到 other 分支，git merge master ，形成图三，other 的指针移动，没有产生新的 commit。

Git rebase

Rebase 实际上是取出一系列的提交记录，“复制”到需要的分支上。Rebase 的优势是可以创造线性的提交历史。

在 master 分支下git rebase other ，即将 master 分支上进行的变动复制到 other 分支上，从而使 master 分支合并 other 分支的修改。切换到 other 分支，git rebase master ，形成图三，other 的指针移动，没有产生新的 commit。这里 other 分支原来的 commit 已经没有指针指向它，但在一定时间内他还是存在的，可以通过 commit 序号指定。

Git merge 与 Git rebase 的比较

参考：简书：闲谈 git merge 与 git rebase 的区别

merge 是一个合并操作，会将两个分支的修改合并在一起，提交合并中修改的内容。merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面。
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的提交后面。rebase 的提交历史反映了项目过程中发生了什么，关注点在开发过程上面。

merge 与 rebase 都是非常强大的合并命令，没有优劣之分，使用哪一个应由项目和团队的开发需求决定

冲突处理

git merge

遇见冲突后会直接停止，等待手动解决冲突并重新提交 commit ，才能再次 merge。merge中遇到的冲突会在文件中标记出来。整个流程为：

假设我们在 master 分支上执行了 git merge other，此时，提示出现冲突无法自动合并
当前暂存区和工作区未成功合并的文件已被标记 “<<<<<<< HEAD \n … \n ======= \n … \n>>>>>>> “, 还未生成新的 commit ，命令行中的分支名变为 “ other| MERGING” （这里突然不想 merge 了怎么办？用 git reset [–hard] 将暂存区与工作区恢复为 commit 的内容。）
按照需要修改完未成功合并的文件后
进行一次 git add , git commit 操作，此时生成的 commit 即为合并后的 commit。也就是说，一般不需要在进行 merge。这里 Git 的判定成功合并是出现了git add , git commit的操作，而无关修改了多少（完全可以带着奇怪的标识符完成 merge （然后编译出错（

git rebase

遇见冲突后会暂停当前操作，开发者可以选择手动解决冲突，然后 git rebase --continue 继续，或者 --skip 跳过（注意此操作中当前分支的修改会直接覆盖目标分支的冲突部分），或者 --abort 直接停止该次 rebase 操作。整个流程为：假设我们在 master 分支上执行了 git rebase other，此时，提示出现冲突无法自动合并：

当前暂存区和工作区未成功合并的文件已被标记, 命令行中的分支名变为 “ other|REBASE x/x” （当前所处的commit 为 other 分支所在的 commit ）
按照需要修改完未成功合并的文件后，进行一次 git add , git commit 操作，即可用 git rebase --continue 继续合并。
git rebase --skip 跳过合并，则 other 分支的修改会覆盖 master 分支中冲突部分。
git rebase --abort 停止合并，返回 master 分支指向的commit

移动 commit

上面的两个操作主要是应用在分支间的操作，而下面的操作则是对commit 进行操作

Git Cherry-pick

git cherry-pick [commit]将提交复制到当前所在的位置下面。如在master下进行命令：git cherry-pick C2 C4 （这里C2 C4 表示 commit 的序号）。Git Cherry-pick 也可以完成分支合并的工作，但它的主要特点是可以提取特定的 commit ，而不是整个分支。

Git rebase -i

-i 是 --interactive 的缩写，也就是交互式 rebase。Git rebase -i [commit] 可以对从指定 commit 到当前commit 直接的 commit 进行排序，合并或删除等。在 Git 中，会通过 vim 打开一个文件，可以在文件中进行调整。Git rebase -i 的主要功能在于调整一个分支上的 commit 。(具体就不介绍了（x