Git 初学

一、需求的产生

二、版本控制系统理解

1. 认识版本控制系统

2. 版本控制系统分类

（1）集中式版本控制系统

缺点：

（2）分布式版本控制系统

三、初识 git

四、git 的使用

例：将 “ 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：查看提交信息。

后续学习再行更新。