认识 Git
那么首先，先让我们简单介绍一下强大的 Git 。本章只介绍 Git 的有关概念，并不涉及过多命令操作。 若想学习命令，请移步Git 的基础操作。
Git 是什么？
Git 是一个分布式版本控制系统，用于辅助开发。它可以帮助你管理代码版本，并有条不紊地同他人协作。
上面的描述比较抽象？不妨代入一下这个情景：
假如老板让你和同事甲共同写一个软件
首先，第一个问题就来了 —— 你们两个人之间怎么才能知道对方代码是怎么写的呢？有朋友可能立刻回答：“微信！” 呃……也许微信确实可以传代码，但是想象一下：你们二人每同步一次工作进度，你就要把甲发来的代码复制并粘贴到你的代码文件里，如此反复。
当项目比较小的时候，这种方式或许还可行，但是一旦项目中代码量达到一定程度，再这样原始地手动同步对方的代码就太没效率了。 这时， Git 的同步功能就可以帮上你的忙。Git 可以用极其高效的方式自动维护双方各自的代码文件夹，使它们能够保持一致。 这下，通过 Git 的协作功能，你不再需要来回 Ctrl+C Ctrl+V 对方的代码了！
利用 Git 的协作功能，你和甲顺利地完成了老板的任务。
你们这个界面不行啊，能不能再花哨点？现在这个太素了。
你的老板如是说。
于是你们开始爆改代码。
在改了 114514 版之后 ——
我还是觉得第一版好。
好。老板，你赢了。但是别急，还好 Git 本身就是一个版本控制系统！它完整地保留了你们二人每一次提交（commit，详见后文）对文件所做的更改！
这样一来，你就可以像 Ctrl+Z 一样，撤销掉第一版到第二版之间所有的代码更改，把你的代码仓库恢复到第一版时的状态！
相信通过这个小故事，你一定理解了为什么我们需要 Git 这个开发神器。没有它，开发的效率将会大大降低。 此外，它还具有其他很多功能有助于开发者管理代码，比如分支管理、分支合并等。
你需要知道的 Git 概念和术语
现在，让我们简单看一下 Git 相关的概念有哪些。它们将贯穿整套教程，所以需要你下点功夫。
仓库 Repository
代码仓库（Repository），简称 Repo（这是你可以在 Issues 和一些技术文档里看到的通用说法）。
它的本质其实就是一个文件夹（或者更专业一点，开发者们通常叫“目录（Directory）”，这两个名词指的是同一个东西）；不过相较于普通的目录，它会有一个名叫 .git 的子目录。
注
在编程领域，人们通常使用 父 子 来表示不同层级之间对象的关系。就像集合一样，我们有 子集 的概念。
父 一般指外层的、更高层级的东西，比如下面的示例中，your-repo 就是 .git 的父目录。相对的，.git 就是 your-repo 的子目录。
就像这样：
hooks
info
logs
objects
refs
config
description
...
some-other-dirs
some-other-files
.git 目录十分重要，它是 Git 在这个代码仓库（目录）下的数据库，存储着仓库中所有代码变更、分支等信息。
如果你看不到 .git 目录
默认情况下，.git 目录是隐藏的。你需要在文件资源管理器中设置“显示隐藏文件”才能看到它。
永远不要尝试手动修改 .git 目录下的任何文件！
你当且仅当使用 git 命令来间接修改它们。 手动修改可能会对当前 Git 状态造成不可预测的影响，如果你不希望你的 Git 环境变得乱糟糟的，那别动这个目录下的文件！
当然，你无须手动一个个创建 .git 中的文件和目录。在下一章，你将会学习基础的 Git 命令，快速创建一个这样的仓库。
提交 Commit
提交，英文是 Commit 。这个东西很像一个照相机，可以把仓库当前的状态完整地记录下来，就像对整个项目拍了张照一样。 当 Git 保存下此刻的状态之后，在以后的任意时刻，只要你的 Git 数据库还在，你就可以恢复当时仓库的情况。
类比相片
如果把每个 提交（Commit） 比作一个照片的话，你可以借助这个神奇的照片，随时穿越回按下快门（执行 git commit 命令）的那一刻。
特别说明的是，Git 的提交是增量式的，也就是说它只会记录自上次提交以来发生的更改，而不是整个项目的快照。这使得 Git 相比其它备份方案更节省空间。
所以，如果你有第一版时的提交记录，那么老板再找你要第一版的时候，你就可以愉快地调出当时的代码。
深入了解 Commit
在你每一次提交代码后，你可以得到一串“乱码”。但是实际上，这串意义不明的字符是这次提交的 哈希值 ，我们称之为 Commit ID，或者 Commit Hash。 在 Git 中，它对于每个 Commit 是唯一的，你可以通过 Commit ID 找到对应的 Commit 。可以说 Commit ID 就是对应提交的“身份证号”。
它的原貌大概长这样：a3c9f1e76c8a4d8fbc69d7e4a6b2478c2b3d9c5a 。这是一个40位的哈希值。不过每一次键入命令的时候敲这么长不是很现实，且一般来说 Commit ID 的前七位足以区分各个 Commit ，所以你可以把上面的 Commit ID 缩写成下面的样子：a3c9f1e 。多数条件下，你在 GitHub 等网站上看到的也是 7 位的 Commit ID
通常，你可以在图形化界面中看到类似这样的图，我们管它叫 Commit Graph 或者 Git Graph 。
在这个图中，每一个圆点表示一次 Commit 。圆点边上那个就是每一次提交对应的 Commit ID 。至于上面那个粉的线是什么，我们马上就讲。
分支 Branch
对，上面图中 main 和 develop 就是 分支，英文称作 Branch。
这个功能，对于大型项目的开发极其必要。在代码量非常非常大的情况下，你要如何做到自己的改动不会影响到别人的工作呢？
已知：项目结构很复杂，你动一个文件可能整个项目都跑不起来。此时，如果所有人的工作进度都完全一样，那么只要有一个人不小心把自己不能正常运行的代码同步给了所有人，那么所有人都干不了活了。
分支就可以用来解决这样的问题，看下面这张图：
这张图中，main 和 dev1 到 dev4 就是五个不同的分支。每个分支的代码改动是相互独立的，直到分支被合并（Merge）。 也就是说，在每一个分支内，不同的项目组可以同时开发不同的功能而互不干扰。当某分支的代码没问题之后，再合并到主分支（main）， 这样就保证了 main 分支代码始终都是可用的，并且保持各个功能开发的独立性。
后面我们会提到 GitHub 的 Pull request 功能，它也是基于合并的原理进行的。
结语
对于刚开始探索 Git 的新手，这些知识已经足够。
接下来，你将正式接触到 Git 的常用命令，以及 GitHub 的相关知识与用法。
