设置git本地仓库

---

在前面两个章节中已经学习了git的基础知识，在本章和下章讲学习git版本控制比较核心的一些操作。(由于本章中的部分内容来自其他文献，可能有的地方可能理解起来不是太易懂，比如在文中分支那一部分的结构图把箭头看成反向的可能更容易理解。)
Git本地仓库：指的是开发者开发设备中的仓库。此章节较长，请做好心理准备，耐心阅读。( :

一、基础操作

任意目录(建议开发根目录)右键 > Git Bash Here，打开git命令行窗口。

1. 配置用户
   配置用户的意义在于记录开发者信息，以便在版本控制记录开发者的操作行为，如cuiht于2018-11-15解决了一个bug。

git config --global user.name "名字"//配置、修改当前用户的名字
git config --global user.email "邮箱"//配置、修改当前用户的邮箱
git config user.name//查看当前用户的名字
git config user.email//查看当前用户的邮箱
--global 配置当前用户所有仓库
--system 配置当前计算机上所有用户的所有仓库
注：配置用户只需要执行1次，可以重复使用。

配置用户.png

3. 初始化仓库
   我们如果想要利用git进行版本控制，需要将现有项目初始化为一个仓库，或者将一个已有的使用git进行版本控制的仓库克隆到本地。
   a. 新建仓库git init git init只是创建了一个名为.git的隐藏目录，这个目录就是存储我们历史版本的仓库，ls -al 可以查看。
   
   



5. 新建仓库.png
   b. 克隆已创建好的仓库git clone 仓库地址 如下，执行完克隆命令，会在当前目录下生成一个eme目录(默认和仓库名称相同)，这个便是已有一个使用Git管理的项目。
   
   



7. 克隆已创建好的仓库.png
   
9. 查看文件状态
   初始化仓库后便可以进行开发了，进入到刚刚创建好并初始为仓库的目录，添加我们开发需要的文件。
   通过git status检测当前仓库文件的状态。(注：git会忽略空的目录)
   
   



11. 查看文件状态.png
    
13. 添加文件到暂存区
    经过一段时间的开发后，需要把已开发的部分存起来，使用git add 添加到暂存区。git add 文件名/ 文件路径 “*”或-A代表所有。放到暂存区的文件被标记成了绿色，等待提交。(注：颜色是工具给添加的，目的是增加可读性并不是git统一的。)
    
    



15. 添加文件到暂存区.png
    
17. 撤销更改
    在开发过程中，我们对某一个文件更改过后发现，发现项目出现bug或者需要撤销更改时，可以通过git checkout 文件名将暂存区域中的文件还原到项目目录。先通过git status查看一下有哪些文件已经被更改过了(更改的文件会被标红)，然后在被更改的文件中选择需要还原的文件进行还原。
    
    



19. 撤销更改.png
    
21. 提交到本地仓库
    在经过一个开发周期完成一个相对比较完善的功能后，就可以提交到本地仓库了，永久保存了。通过git commit -m '备注信息'进行提交。也就是将暂存区被标记成绿色的文件，全部提交到本地仓库存储。
    
    



23. 提交到本地仓库.png
    
25. 重复提交
    在之后的开发周期中，又完成了一些相对完善的功能重复步骤3到6进行重复提交。
    8.查看提交历史
    经过一段时间的开发，已经提交了很多次，这时候我们可以通过git log查看提交历史。
    我们可以查看到一条条类似commit 81b1e4fc2ae178caedf4575596377a80a6f1e73f提交记录,commit后面的字符串代表一次提交的唯一ID，一般称为SHA值。(注：按键盘q键退出。)
    
    



27. 查看提交历史.png
    
29. 恢复之前某一次提交的状态
    使用SHA值可以回到之前某一次的提交。通过git reset --hard SHA值这样便回到了之前某一次的提交的状态，git log再次查看发现最后一次提交我们要恢复那一次的提交。
    
    



31. 恢复之前某一次提交的状态.png
    
    
    



32. 
    

二、 分支
在我们的现实开发中，需求往往是五花八门的，同时开发个需求的情况十分常见，比如当你正在专注开发一个功能时，突然有一个紧急的BUG需要你来修复，这个时候我们当然是希望在能够保存当前任务进度，再去修改这个BUG，等这个BUG修复完成后再继续我们的任务。
通过Git创建分支来解决实际开发中类似的问题。在Git的使用过程中一次提交称为历史记录(版本)，并且会生成一个唯一的字符串，就是我们之前提到过的SHA值，这个SHA值可以代表某一个历史版本(实际使用只取前面几位就可以)。
值得注意的是所有的提交(commit)实际上都是在分支(branch)的基础上进行的。

分支上提交示意图.png

当我们在初始化仓库的时候(实际上是产生第1次提交时)，Git会默认帮我们创建了一个master的分支，并且有指针(HEAD)指到了末端。
指针(HEAD)用来标明当前处于哪个分支的哪个版本，如上图指的处于master分支的最后1个版本。我们也可以创建自已的分支，协助开发。

2. 创建分支
   通过git branch 分支名新建分支，新的分支会在当前分支原有历史版本的结点上进行创建，可以称其为子分支。新建的子分支会继承父分支的所有提交历史。
   
   



4. 分支结构.png
   
6. 切换分支
   通过git checkout 分支名切换分支。我们发现HEAD现在又指向了切换的分支的末端。
   
   



8. 切换分支.png
   
   这时候我们可以查看一下提交历史。会发现我们依然可以看到之前提交的记录。
   
   



9. 
   
11. 在新分支上提交
    修改bug后，进行提交，步骤和之前的步骤一样。这次的提交历史版本就会记录在新分支上了，并且HEAD伴随新分支在移动。
    
    



12. 
    
    
    



14. 在新分支上提交.png
    
16. 回到主分支继续工作
    当我们切换回master后，HEAD指向了master分支的末端，并且我们观察发现我们的文件内容还是原来的“模样”。
    
    



17. 
    
    
    



19. 切换回master分支.png
    
    在我们回到主分支继续工作，并提交代码后，版本库的结构就会类似于下面
    
    



21. 继续工作版本库结构.png
    
    当我们git checkout branchname时，HEAD会自动指向对应分支的末端，工作目录中的源码也会随之发生改变。这个时候我们就在新分支上修复了这个BUG，而我们原来在master分支上的操作并未受到影响。从上图可以看出这时的master分支并没有包含有新分支的修复，两个分支类似于并行，这时候我们就会面对一个新问题合并分支。
23. 合并(融合)分支
    通过git merge 分支名合并分支，在这里需要注意的是用命令行提交分支的前提是要会使用vi编辑器，第一次合并可能需要vi编辑配合，如果不会的话建议参看一下合并分支使用可视化工具进行融合。下面是我的操作记录可以看一下。
    
    



24. 
    
    由图片可以看到在切回主分支是是看不到子分支的提交记录的，在分支融合后，就可以看到子分支的提交记录了，这就代表分支已经融合了。
26. 删除分支
    在分支融合后，那个子分支就没有用了，可以通过git branch -d 分支名删除掉。
    
    



27. 
    
    
    



29. 删除分支.png
    

git 版本控制工具本地操作的相关操作到这里就告一段落了，下一章节将继续学习git 远程仓库的相关操作。
多用心去倾听别人怎么说，不要急着表达你自己的看法。