Git是什么？

想象如下场景，你正在给客户写一个方案，通宵熬夜终于写好了1.0版本，你使用word来存储，保存在你的D盘的方案目录下：

D:/方案
- **方案-1.0.doc

客户看了以后，给你提了一些意见，于是你对方案进行了调整，为了保存历史记录，你拷贝了1.0版本，改名为2.0版本，然后又提交给客户看，现在你的文档目录如下所示：

D:/方案
- **方案-1.0.doc
- **方案-2.0.doc

客户看了之后，还是不满意，于是你有了3.0版本：

D:/方案
- **方案-1.0.doc
- **方案-2.0.doc
- **方案-3.0.doc

客户看了之后比较满意了，说再稍微调整一下就可以了。此时已经比较晚了，你打算回去进行修改。于是你用U盘或网盘将文档拷贝回去，在自己家里的电脑上进行编辑，编辑完之后，第二天又用U盘或云盘将文档拷贝回了公司的电脑。终于，你完成了最终版：

D:/方案
- **方案-1.0.doc
- **方案-2.0.doc
- **方案-3.0.doc
- **方案-最终版.doc

当你满怀信心的将最终版方案给客户看了之后，客户又提出了建议，你面带微笑骂骂咧咧的回来，又改了最最终版：

D:/方案
- **方案-1.0.doc
- **方案-2.0.doc
- **方案-3.0.doc
- **方案-最终版.doc
- **方案-最最终版.doc

最后，客户来了一句，还是按照第一版来吧。你吐血！
对于上面的每一个文档，实际都是一个版本。我们目前是通过手工拷贝的方式来进行版本的管理。对于单个文件还好，如果你需要同时管理多个文件的版本，比如：项目代码。那么这种方式显然是不可取的。
此时，你就需要版本管理软件来帮你完成手工拷贝的工作。而Git就是一种版本管理软件。

使用Git管理

我们来看一下，上面的场景，我们通过git如何来进行管理。
首先，我们通过git init 方案命令来初始化方案目录，进入方案目录后，我们依然创建方案文档，此时的目录看起来像这样：

D:/方案
- **方案.doc

此时的目录结构和之前没什么太大的区别。我们编写完文档后，通过如下命令存储一下文件：

git add **方案.doc
git commit -m '1.0版本'

然后，我们把文档给客户看，客户不满意，我们需要进行修改。此时，我们不需要拷贝一份文档进行编辑，可以直接在对应文档上进行修改。修改完成后，执行类似下面的代码进行版本管理。

git add **方案.doc
git commit -m '2.0版本'

期间，你需要回家加班。此时你不需要云盘或网盘，只需要通过git push origin master命令，将文档推送到远程服务器即可。到家之后，你直接通过git clone ***命令，将文档下载到本地电脑，编辑完成后，通过如下命令提交：

git add **方案.doc
git commit -m '3.0版本'
git push origin master

回到公司后，你通过git pull origin master命令将最新的文档下载下来，即可继续编辑了。
最后，如果客户还想要1.0版本，只需要根据对应的id进行checkout即可。

Git概念模型

对上面的命令我们进行汇总，一般我们使用得比较多的Git指令如下：

# 初始化git
git init test-dir
# 添加文件到暂存区
git add test.txt
# 提交到本地仓库
git commit -m 'test'
# 推送到远程仓库master分支
git push origin master
# 检出branch-01分支
git checkout -b branch-01
# 合并master分支
git merge master
# 推送到远程仓库branch-01分支
git push origin branch-01

上面的指令涉及到了如下概念：

• 工作区：就是我们编写内容的目录。对应上面的例子，就是「方案」目录
• 暂存区/索引区：当我们执行git add指令时，git会将对应文件添加到暂存区/索引区
• 本地仓库：可以理解为是本地数据库，提交信息会在此处记录
• 远程仓库：远程仓库和本地仓库本质上是一样的（后面的内容会进行详细的说明），只是一个在你本机，一个在远程。
• 分支：你可以理解为数据库中的一张表，和真正的数据表区别的地方是，每个分支的Schema都是一样的，并且可以合并。
  整个过程如下图所示：

总结

本文通过一个简单的示例，来快速梳理Git，让大家对Git有一个初步的认识。下面将通过一个详细的例子，来阐述Git的实际使用。