前言

本来不打算写相关Git系列教程，因为网上已有廖雪峰老师的《Git教程》，及扔物线老师的《Git原理及使用指南》，怕自己写不好，写不全，讲不清。但自己学习 Git 后，又按捺不住想写的冲动，所以最终我还是动笔了。为了让初次接触 Git 的小伙伴快速上手，整个系列不打算深入的讲解Git，而会将重心放在Git的常用概念及频率较高的Git命令。同时又因为笔者是一名爱岗敬业的Android程序员，所以在文章中，我也会介绍Git相关指令在 IntelliJ IDEA 与 Android Studio 图形化界面上的对应实现。

总之，简单一句话来说，整个系列文章能帮助大家，不仅学到 Git 相关概念及 Git 相关命令的使用，还能熟悉图形化界面上的操作。装逼(论一个习惯命令行的程序员的自我修养），偷懒两不误~，还在等什么呢？少年！！！come on ~

整个系列的文章，结合了相关视频与博客，在文章末尾或文章中都给出了相应学习链接。只有站在巨人的肩膀上，才能看的更远~

什么是版本控制

在我们进行深度学习 Git 之前，我想给大家讲个故事，时间回到我们青春岁月的大学时代，在大四的小伙伴们，我相信大家都经历过毕业论文👨‍🎓的折磨。在无数遍咒骂导师的时候，我们将毕业论文改了一遍又一遍。《绝不修改版本1》，《修改剁手版本1》，《打死不改版本》，《改了，导师挂全家版本》....等等，随着论文修改的版本次数增加与时间长短等其他原因。我们或许已经忘记在相应版本中，我们添加了什么内容，删除了哪些语句。想要从不同版本中找到我们的历史记录，这是一项非常困难的事。

而版本控制系统就能帮助我们解决上述我们遇到的问题。版本控制系统的主要目的是帮助你保留项目的详细历史记录，并且能够在不同的版本上进行工作。保留详细的项目历史记录很重要，因为这样可以看出一段时间内项目的进度。如果需要，你还可以回到项目的某个阶段，并恢复数据或文件。

版本控制其实就是 控制版本 ，版本控制系统就是帮助我们控制或管理某个事物的不同版本

集中式or分布式

现在市面上的控制系统有几十上百种，但是最为流行的版本控制系统为下面三者：

尽管有着不同的版本控制系统，但其主要类别分为两种：

集中式模型：所有用户都连接到一个中央的仓库(master repository)
分布式模型：每个用户都在自己的计算机上拥有完成的仓库。

在集中式模型中，有一台功能强大的中央服务器托管项目。每个每户都必须通过这台中央服务器。

在分布式模型中，没有中央信息库，每个开发者的计算机都有一份完整的项目拷贝。因为每台计算机都有完成的项目拷贝，这就意味着我们可以离线工作，不受网络的限制了。

在该系列文章中，我们将使用Git，它是分布式版本控制系统。你可能听说过 GitHub , Git 和 GitHub 是完全不同的 Git 是版本控制工具。而 Github 是托管 Git 项目的服务，要使用 Git 项目，你未必要使用 GitHub 。但是 GitHub ,在后续文章中我们也会讲到。现在就把它当做可以上传你的项目副本的另一台计算机。如果现在没有理解集中式，分布式。也完全没有关系。这里只是介绍一下他们运行的大概框架。

Git和版本控制术语

在学习Git之前，我们有必要了解Git和版本控制术语，了解相关术语，有助于我们更好的学习并使用Git。

版本控制系统或源代码管理器

版本控制系统（version control system 简称VCS）是一个管理源代码不同版本的工具。源代码管理器（source code management 简称 SCM）是版本控制系统的另一个名称。

Git 是一个 SCM（因此也是 VCS！）。Git 官方网站的 URL 是 https://Git-scm.com/（注意它的域名中直接包含“SCM”！）。

提交(cmomit)

Git 将数据看做微型文件系统的一组快照。每次 commit（在 Git 中保持项目状态），它都对文件当时的状况拍照，并存储对该快照的引用。你可以将其看做游戏中的保存点，它会保存项目的文件和关于文件的所有信息。

你在 Git 中的所有操作都是帮助你进行 commit，因此 commit 是 Git 中的基本单位。

仓库(Repository/repo)

仓库是一个包含项目内容以及几个文件（在 Mac OS X 上默认地处于隐藏状态）的目录，用来与 Git 进行通信。仓库可以存储在本地，或作为远程副本存储在其他计算机上。仓库是由 commit 构成的。

工作目录 / 工作区（Working Directory）

工作目录是你在计算机的文件系统中看到的文件。当你在代码编辑器中打开项目文件时，你是在工作目录中处理文件。

与这些文件形成对比的是保持在仓库中（在 commit 中！）的文件。

在使用 Git 时，工作目录与命令行工具的 current working directory （当前工作目录）不一样，后者是 shell 当前正在查看的目录。

检出（Checkout）

检出是指将仓库中的内容复制到工作目录下。

暂存区 / 暂存索引 / 索引（Staging Area / Staging Index / Index）

Git 目录下的一个文件，存储的是即将进入下个 commit 内容的信息。可以将暂存区看做准备工作台，Git 将在此区域获取下个 commit。暂存索引中的文件是准备添加到仓库中的文件。

SHA

SHA 是每个 commit 的 ID 编号。以下是 commit 的 SHA 示例：

e2adf8ae3e2e4ed40add75cc44cf9d0a869afeb6。

它是一个长 40 个字符的字符串（由 0–9 和 a–f 组成），并根据 Git 中的文件或目录结构的内容计算得出。SHA 的全称是"Secure Hash Algorithm"（安全哈希算法）。如果你想了解哈希算法，可以参考SHA家族。

分支（Branch）

分支是从主开发流程中分支出来的新的开发流程。这种分支开发流程可以在不更改主流程的情况下继续延伸下去。

回到之前关于游戏保存点的示例，你可以将分支看做在游戏中设立保存点后，尝试一个有风险的招式。如果有风险的招式不奏效，则回到保存的位置。令分支非常强大的关键之处是你可以在一个分支上设定保存点，然后切换到另一个分支并继续设定保存点。

Git的工作流程

在Git的工作流程主要围绕三个部分，工作区，暂存区与仓库区。当你第一次在使用Git时，可能不太容易意识到有这三个不同的区域。因为你并不会在计算机的文件中看到任何可见的修改。但Git的确管理者这三个区域。

向仓库中添加文件

在Git中如果你创建了一个空仓库，Git能够分辨从未见过的文件，如上图中的红色的A文件，如果我们需要通过Git来跟踪我们的文件，我们需要将文件添加到仓库中，但是我们不能直接将这些文件直接移动到仓库区中。上述A文件必须先移动到暂存区，我们可以使用 git add 指令将A文件更改移动到暂存区(暂存区可以存放所有即将提交的文件)。当文件提交到暂存区中后，我们可以使用git cmomit指令将A文件移动到仓库区去。

关于 git add 与 git commit 这两个指令，在接下来的文章中会进行讲解。需要注意的是只有暂存区的内容才会被提交到仓库中去。

修改仓库中的文件

同样的修改仓库中的文件，也需要先将修改的文件先添加到暂存区中，然后从暂存区提交到仓库。

浏览提交记录

如果说我们想查看我们的提交信息怎么办呢？针对每个提交，Git都会为其创建一个 ID（SHA) ,每个提交的ID，也就是SHA的前七个字符如下图所示：

最后

站在巨人的肩膀上，才能看的更远~