目录
[1. 认识版本控制系统](#1. 认识版本控制系统)
[2. 版本控制系统分类](#2. 版本控制系统分类)
[三、初识 git](#三、初识 git)
[四、git 的使用](#四、git 的使用)
[例：将 " OLED文件夹 " 添加到笔者的 gitee仓库中。](#例：将 “ OLED文件夹 ” 添加到笔者的 gitee仓库中。)
一、需求的产生
在软件开发过程中，每实现一个功能，每前进一步，都要赶紧存档备份，保存为一个版本，然后以这个版本为基点进行下一个版本的开发 。客户不停地提需求，改需求，你就不停地备份版本。这就像写毕业论文一样，你不停地改论文，导师不停地打回来，到最后就变成了这个样子。
不同版本的论文之间 到底修改了哪些东西 ？时间久了，可能也就 慢慢忘记了。有没有更好的方法去 记录这些详细的变化呢 ？ 答案是有的。我们可以 使用 版本控制 系统 来记录每一次的 修改和变化。
二、版本控制系统理解
1. 认识版本控制系统
版本控制系统会跟踪并记录一个项目中每一个文件的变化：谁创建了它，谁修改了它，又是谁删除了它，是什么时候，修改了什么内容，都一一记录在案。有了版本控制系统，工程师之间互相推卸责任的机会大大减少了，你修改了什么，都有详细的记录在案，都保存在版本库中，铁证如山，随便翻一翻就可以查得到。
2. 版本控制系统分类
版本控制系统一般分为：集中式版本控制系统和分布式版本控制系统。
（1）集中式版本控制系统
其软件的各个版本快照只保存在服务器上，服务器中包含各个版本的软件代码。用户如果想要观看某个版本的代码， 首先要从版本库中将该版本的代码拉取到本地的计算机上，然后才能查看和修改，最后将自己的修改保存到服务器上。
缺点：
① 数据存储在 服务器上，使用时要 联网：员工直接登录服务器 删库 跑路，如果数据没有备份，问题就很严重，基本上就 很难恢复了。
② 收费：远远 没有免费的分布式版本控制 系统受 欢迎。
（2）分布式版本控制系统
不再将整个版本库保存在一个服务器上，而是保存在每个员工的计算机中。
好处：
即使服务器 崩溃了，或者离职的员工删除了服务器的代码，只要 数据在任何一个员工的计算机中有 备份，都可以 直接恢复，因为 每个计算机保存的版本库数据 都是一样的。
集中式 和 分布式版本 控制系统 典型的代表就是 小乌龟和 Git 。
三、初识 git
学习git，首先要明白几个重要的基本概念：++工作区（Working Directory）、暂存区（Staging Area） 和版本库（Repository）。++
版本库 里保存的是我们提交的 多个版本的代码快照 ，如果想查看某个版本的代码，可以通过 git checkout命令将版本库里这个 版本的代码拉取出来 ，释放到 工作区。
在工作区 ，可以浏览某一个版本的代码、修改代码 。如果想 把自己修改保存到版本库中 ，可以先将修改保存到 暂存区，接着修改，再保存到暂存区，直到 真正完成修改，再统一将暂存区里所有的修改提交到 版本库中。
为什么还需要一个暂存区呢？将工作区的修改直接提交（Commit），保存到版本库中岂不是更方便？
答：
对于一个版本库来说，你的 任何一个提交，包括修改、添加文件、删除文件等 操作都会有一个记录 ，而在 实际工作中，对于一个 工程师来说，在 开发一个功能时，可能会分成很多步，如果每一小步都去 提交一次，意义不是很大，而且 不是一个 完整的功能，别人可能就 搞不懂你的提交到底实现了 什么功能。所以将每次 很小的修改都做一次提交，就不是很合适。
从原则上讲，我们的 每一次提交，都是一个 里程碑：要么新增了一个功能，要么修改了一个 Bug，要么优化了一个功能。在实际开发中的 每一小步，都可以 先保存到暂存区，等整体功能 完成后，再统一 提交比较合理。
四、git 的使用
例：将"OLED文件夹"添加到笔者的gitee仓库中。
1. 在此文件路径下打开命令。
2. git init ：在此路径下初始化Git仓库。
如果初始化成功，将会生成 .git 目录。这个 .git 目录 里存储着 ++管理当前目录内容所需的仓库数据++ 。在 Git中，这个目录的内容被称为 " 附属于该仓库的工作树 " 。文件的编辑 等操作在工作树中进行，然后 记录到仓库中，以 此管理文件的历史快照。
如果想将文件恢复到原先的状态，可以从仓库中调取之前的快照，在工作树中打开。开发者可以通过这种方式获取以往的文件。
***补：*此时git status 命令查看 " OLED文件 " 时显示在 Untracked files里。
3. git add OLED ：将工作区的修改"OLED文件夹"添加到暂存区（提交之前的一个临时区域，即Stage 或 Index）。
补：
（1）git status命令 的显示结果发生了变化。" OLED文件 " 显示在 Changes to be committed 中了。
（2）git rm --cached OLED：将 " OLED文件夹 " 从暂存区中 删除。
4. git commit -m "<日志信息（自写）>" OLED ：将暂存区的修改提交到本地仓库，即保存仓库历史记录。（通过这些记录就可以在工作树中复原文件）
补：
（1）git status： 查看文件的状态 。每一步操作后，OLED 的文件状态都会发生变化 ：从untracked 到 changes to be commited，工作区的状态 也会跟着变化。
（2）git log： 查看提交信息。包括提交的 ID、提交作者、提交时间、提交信息说明 等。（ 后加上目录名，便会 只显示该目录下的 日志。如果 加的是 文件名，就会 只显示与 该文件相关的日志 ）
5. 如果想把修改再次提交到本地仓库，可以使用下面的命令。
（1）git add OLED
（2）git commit -m "<日志信息（自写）>" OLED
git show： 查看新的提交信息和修改变化。
6. git remote add origin 远程仓库地址：建立本地仓库与远程仓库的关联。
git remote rm origin：删除关联的origin的远程库。
git pull --rebase origin master：将远程仓库的内容合并到本地仓库。
7. git push -u origin master：将本地仓库的文件推送到已经建立关联的远程仓库master分支中。
基本命令整理：
五、分支操作
在进行多个并行作业时，会用到分支，每个分支中都拥有自己的最新代码。master分支是 Git 默认创建的分支，因此基本上所有开发都是以这个分支为中心进行的。不同分支中，可以同时进行完全不同的作业。等该分支的作业完成之后再与 master分支合并。
如果想让自己提交不影响整个项目，不影响其他人使用，则可以创建一个自己的分支my_branch，切换到 my_brancn分支 上，然后在这个分支上 修改代码 就可以了。提交时 再将自己修改用上面的方法 提交到 my_branch分支 上。通过这种操作，所有修改 都提交到你 自己创建的分支 my_branch 上，而不会影响 master主分支上 的代码，不会影响其他人。
（1）git branch my_ branch ：创建一个新分支 my_branch。
（2）git checkout my_ branch ：切换到新分支my_branch。
（3）git commit -m "on my _brach:modify OLED"：将修改提交到 my_branch。
（4）git log：查看新的提交信息。
（5）git checkout master ：切换到 master 分支，在该分支上看不到新的提交信息。
（6）git merge my_branch ：将 my_branch 分支上的修改合并到 master 分支。
（7）git log：查看提交信息。
后续学习再行更新。