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的实际使用。