閱讀本文約花費: 6 (分鐘)

本文主要挑选几个最简单的例子来讲解Git 实操基础，希望可以加深对具体 Git 命令的操作理解。 本文来自于微信公众号GitHubDaily，

Git 作为居家必备、团队协作之利器，自从 Linus Torvalds 发布这款工具后，便一直受到各路开发者的喜爱。

不过，尽管如此，小 G 还是经常能在公众号后台，看到有不少水友留言反馈，说 Git 里面太多干巴巴，看起来非常枯燥无味的命令行，一旦几天没用，就很容易就忘得一干二净，希望 GitHubDaily 能出一些与 Git 相关的辅助教程，或者比较有趣、对小白比较友好的学习方式。

emmm.. 作为有求必应的小 G，当然是选择尽可能满足大家的一切要求啦。

几天前，小 G 偶然在 Twitter 看到一篇文章：《CS Visualized: Useful Git Commands》。

作者是来自英属哥伦比亚的小姐姐 Lydia Hallie，在这篇文章里面，她通过生动形象的动画，以更加直观的方式，向开发者展示 Git 命令中的 merge、rebase、reset、revert、cherry-pick 等常用骚操作的具体原理。

接下来，小 G 会挑选几个最简单的例子，让你们看看这位小姐姐是如何用动画来进行展示的。

在开始之前，还是得先跟大家简单说一下，这篇文章不算是针对小白萌新的 Git 初级入门文章，而是希望帮助有一定 Git 实操基础的用户，加深对具体 Git 命令的操作理解。

合并（Merge）

我们都知道，在使用 Git 做日常开发项目的时候，都会选择将项目切换成多个分支，在不同分支上处理不同事务。最简单的，就是开发、测试、生产等几个不同环境来回切换，使得项目管理与产品迭代更为轻松，亦可最大化避免项目出现严重漏洞时所带来的伤害。

当我们在不同分支开发完代码后，会选择将分支进行合并（merge）。平时常用的 git merge 操作，又可分为这两种类型：fast-forwar 和no-fast-forward。

fast-forward

一般情况下，Git 会默认使用 fast-forward 这种类型来处理分支合并，当我们成功合并后，不会产生任何提交记录，且当旧分支被移除后，其分支信息也会被一并删除。

通过动画的方式展示，就像下面这样：

no-fast-forward

而当我们使用 no-fast-forward 模式，即在合并分支命令加入 –no-ff 后缀的方式运行时，便会生成一个新的提交记录，就像下面这样：

合并冲突

在我们日常进行团队协作开发的时候，总会出现同个文件在不同分支上被同时编辑的情况。

这样，当我们提交代码的时候，比较晚提交的另一方，在运行 Git 命令时就会报冲突错误。在正常情况下，只要我们手动处理下冲突文件，然后再重新提交即可。

打个比方，现在代码仓库有个 README 文件，在同一行的位置，在不同分支上被编辑了，如下所示：

那么，使用合并命令，及修复冲突的过程，用动画的形式展示，看起来就像下面这样：

可以看到，在移除多余的提示代码后，会重新产生一条新的提交记录。

Rebase

在进行分支合并前，我们一般会先使用pull命令拉取线上的最新代码，在保证无任何冲突发生的前提下，再进行分支合并。

但是，这种代码拉取方式是最为简单粗暴的，通过这种方式合并，会使得整个提交记录看起来特别乱，不太直观与优雅。

因此，对 Git 使用比较规范、追求比较高的程序员，都会先使用rebase整理下提交记录，再提交代码，经过这样处理后的 Git 提交记录，看着就比直男还直了。

以动画的方式呈现，就像下面这样：

可以清晰的看到，原本对接在 master 分支第二处的 dev 分支，被对接到顶部了。

Hard Reset

日常开发中，我们可能会因为提交了某些无用代码而进行回滚操作。通常在只有一个人独立开发的项目情况下，会选用–hard命令来进行回滚处理。

不过，这种操作方式有个不好的地方，在多人协作的时候，这么搞很容易使分支出现冲突，或直接毁掉别人的提交记录。

hard reset以动画的形式表现，看起来就像下面这样：

除此之外，小姐姐还提到了 Reverting、Cherry-picking、Fetch 等一系列操作，这里限于篇幅，就不跟大家一一讲解啦。

感兴趣的同学，可以查看小姐姐文章详情.