Git使用

什么是Git?

        Git是一个版本控制器.假设你设计一个文档,并进行了五次修改,那么最终的版本是第五次修改后的第五版,如果你对第五版的不满意,觉得还是第一版或者第二版的好,你要怎么恢复回去?你可以说会凭着记忆修改回去,或者你每次修改完后都会把每个版本的文件另外保存,那么恭喜你,Git大致做的就是这个工作,你不用每次刻意保存,只需要将你的文档提交到git平台上,他就会帮你记录每个版本的信息,或者你自己添加一些描述,例如对文件做了哪些修改.

        Git平台支持所有类型文件的版本维护,向代码文件,图片文件,文本文件.

        Git是目前最主流的版本控制器.

安装Git –centos

        一条指令,sudo yum install git -y:

         安装成功后查看版本信息,git –version:

初始化git

新建一个目录，切换到该目录下输入指令 git init :

初始化后，该目录下存在一个 .git的隐藏文件，说明初始化成功：

设置用户名和emile地址

        这是两个必须配置的选项，不配置的话，以后向远程仓促推送内容会找不到目标，下面是指令：

git congif user.name ” “

git config user.email ” “

还可以设置为全局，我们一台机器上可以在不同的文件夹下建立多个仓库，将name和email设置为全局，以后再次创建本地仓库的时候，该本地仓库中的配置项会被自动设置，指令：

git config –global user.name ” ” 

git config –global user.email ” ” 

当然还可以删除相应的配置

git config –unset user.name

git config –unset user.email 

如果要删除全局就加上 –global：

git config  –global –unset user.email 

git config -l 用于查看相关的配置项：

add，commit

        在说指令之前，补充说一下，实际上，我们所说的本地仓库，不是我们初始化仓库时的文件目录，也就是与.git隐藏文件同级的目录，我们把他叫做工作区，我们所说的本地仓库实际上是.git隐藏目录，也被叫做版本库，它是如下的结构：

        首先，我们在工作区写我们的文件或者代码，add操作，会将我们在工作区对文件内容的新增，修改，删除进行储存，而记录这些修改，删除，新增信息的数据结构，我们把它叫做git对象，当我们把每次修改的内容都保存下来储存到一个git对象中，也就是意味着记录下了不同的版本。

        git对象被.git目录下的一个区域管理起来，该区域储存着多个git对象，一个git对象代表着一次修改，也就是对应一个版本。

        再回来说add。我们对工作区内容修改一次，版本库创建一个git对象，并为每一个git对象建立索引，add操作将新建的git对象索引储存，然后commit操作推送到master分支中，这里先不需要知道master分支和HEAD是什么。其中，master是一个树结构，每一个分支也是一个索引，指向一个git对象。

下面是指令的演示：

提交以后会出现：

第一行叫做commit，每次提交都会产生一个哈希值来对应，他的作用后面说。

git log

        提交的记录可以用git log指令来查看：

提交后git仓库中的变化

        前面说，每次add后会先创建一个git对象来记录修改的信息并为git对象创建一个索引，然后将该索引暂时存储到暂存区，commit后将索引推送到master，下面我们来验证一下，tree 一下.git目录来查看它的结构变化：

       很容易在git结构目录里面找到我们想看到的，每次commit后产生的id就是新增git对象的索引值。

git cat-file 

        该指令可以通过对应的git对象索引来查看相应的内容，这里用cat-file来查看上次commit后产生的索引：

四行信息，parent是上次commit时的索引，还有作者信息和提交者的信息，第一行的tree我们也来cat一下：

        其中的ReadMe与test文件是与readme文件逐个add后，一起commit的两个文件，再说详细一点，假如你先add了A文件，又add了B文件，又add了C文件，你将三个文件先放到了暂存区，然后一起commit向master分支，这个tree记录的就是你这一次commit时的所有文件。每行信息中还有一个索引，我们接着用cat-file查看，就看readme：

这里直接显示出了你对应commit时修改的内容。

        到这里总结一下，你写好项目add，commit后，git会为你的本次提交产生一个索引，通过cat-file指令+commit id 可以查看本次提交提交记录，cat-file tree会显示本次提交了哪些文件，然后再cat-file具体的git对象索引，就可以查看你本次提交时修改了哪些内容。

git status

        提交后，我们为readme文件新增一行内容：

        然后使用git status命令：

当你在工作区修改了文件，没有add也没有commit时，你可以通过该指令帮你查看相比于上次提交，目前工作区修改了哪些内容，该指令指挥告诉你哪个文件被修改了，具体修改的文件内容要使用git diff。

git diff

        通过上面的git status来查看目前工作区你修改了哪些内容，git diff来查看具体的内容：

        信息用标准的unix的diff格式显示。

版本回退 git reset 

        git是一个版本追踪器，他重要的功能就是能够追溯你修改的不同版本，git reset + commit id能够让你回退到你某一次提交时的版本。

        到目前，readme修改过一次并且提交，第一次readme文件只有一行内容，第二次新增了一行：

目前我们的工作区内是第二个版本的内容，下面我们回退到第一个版本：

这里补充git reset的三个选项 –soft ，–mixed，–hard，

soft只将master分支中的版本回退，

mixed将master和暂存区的版本回退，

–hard将工作区，暂存区和matser分支中的版本都回退

回退成功后，你相应的提交记录也会被改变：

问题就来了，使用hard选项将新版本回退到旧版本，你现在怎么回到你的新版本？？你最新提交的commit id丢失了！

所以hard选项是一个慎用的选项，上面用hard选项演示是因为工作区的版本回退以后容易观察到现象。

用另一个命令解决该问题 git refog

git reflog

        你在某个版本中使用的git指令可以用 git reflog查看，第一列的的短哈希值就是你在某个版本使用指令的版本索引。到这里再解释一下，你每次commit都会产生一个commit id，git就认为你每次提交就是一个不同的版本，所以只要能找到你某次提交时的commit id，你就能reset到相应的版本。

reflog 中记录的是commit id的短索引，通过短索引也能定位到你某次的提交。

所以，版本间的切换最重要的就是你需要找到某次提交时对应的commit id，如果找不到的话，那也就没办法切换到你相应的版本。

git checkout — 文件名

         撤销修改1

        当你提交了一次项目，然后你又继续在工作区对项目进行了修改，修改后你没有add，也没有commit，你这时你后悔对项目进行了改动，想要恢复到上次commit时的样子，这个时候就用git checkout — 文件名。

        我们在readme文件中新增一行内容，不进行add和commot，使用git status可以看到此时工作区与版本库中的内容不同，提示我们readme文件被修改了，接下来使用git chechout — readme指令来回到最近一次提交的版本：

撤销修改2

        你提交过一次项目后，对项目进行了修改，并且进行了add，没有commit，此时你想恢复到上次commit时的样子。

        还记得git reset吗，它的三个选项，soft只对master分支的版本回退，mixed 将master分支和暂存区进行回退，hard将工作区，暂存区和master分支都回退。

        这里我们用mixed选项来演示，该选项是将master分支和暂存区回退，并且是一个默认选项，所以直接 git reset HEAD readme：

HEAD

        这里没有用 git reset + commit id，在说git内部结构的时候，HEAD指针没有介绍，我们这里

说一下：

        结论就是，HEAD指针是一个指针，它指向了最近一次提交的代码。

---

        继续说我们的撤销修改，我们怎么观察暂存区的内容回退了呢？？

在撤销修改1中，我们只修改工作区的内容没有add时使用git status 有这么一行提示 Changes not staged for commit，当我们修改工作区的内容并且add后使用git status提示是：Changes to be committed，所以我们使用了git reset将暂存区回退以后，再使用git status，给出的提示应该是Changes not staged for commit，提示你修改没有存储到暂存区：

        结果验证咯。

        这个时候你想恢复到工作区的内容，就来到了撤销修改1的情形，使用git checkout — 文件名。

        以上撤销修改的前提是你所有的修改都只是在本地仓库进行，没有push到远程仓库。

git rm 

        将文件从工作区和暂存区删除有两种方式。

        1. rm 删除文件后，使用add保存修改，然后提交到仓库：

       git版本是2.0以前的会忽略删除的文件，要加上-A选项，如果是2.0以上的可以不加- A选项。

        2. git rm指令，实际上就是将上面的两步合并：

分支

        git的另一个功能就是多人协作开发，之前的所有内容是针对个人对代码版本维护的常用操作，分支功能可以实现多人协作开发。

        git仓库初始化之后会自动创建一个名叫master的主分支，企业中，一个项目是非常大的，常常需要多人分别负责不同的模块。我们假设有一个项目Y，该项目由三个功能模块构成，分别是A，B，C，将这个项目分别交给三个人，三个人在自己本地仓库master分别完成了相应的功能模块，三个人分别进行了push，那么最后的结果就是，最后的代码版本只是三个人其中之一的功能模块而不是三个人本地仓库合并以后的完整项目。

        但是如果三个人分别在不同的分支完成自己相应的功能实现，最后将三个分支合并再push，那么最后的结果就是一个完整的项目。

        下面我们先介绍指令，然后做总结的时候来看一下是不是像上面抽象的那样。

查看分支：git branch

        查看当前的分支结构：

        当前只有master分支。

新建分支：git branch + 分支

  切换分支：git checkout + 分支名

一步新建分支+切换分支：git checkout -b + 分支名

---

        我们这时候看一下.git版本库的变化：

        首先，我们创建并切换分支成功后，HEAD的内容发生了变化，并且refs的heads路径下多了一个sector1文件。结论是：.git中的HEAD代表我当前所在的分支

       之前我们曾打开过heads文件下的master的内容，是一个commit id，下面我们比较新建的分支内容和master内容，然后跟提交记录做对比，之后我们在sector1分支下进行一次commit，再次观察此时二者内容有什么不同：

        两个分支都是指向了最近一次的提交，接下来我们再sector1分支中进行一次提交，观察提交记录的变化以及HEAD指针：

        

       新建分支是基于你此时master的版本，然后一个分支的提交修改不影响你其他分支的提交修改，当各自的模块完成后就可以合并。

合并分支：git merge + 分支名

        需要先切换到master分支然后再指向git merge

删除分支：git branch -d + 分支名

        当分支合并以后，其他被合并的分支就可以删除，需要注意的是，如果你要例如sector1分支，你需要先切换到其他分支才能删除它：

 分支合并冲突

        我们在当前版本上新建一个分支，然后再master分支内对文件修改并提交，在对新分支内相同的文件做不同的修改然后再提交：

 然后合并两个分支看发生什么现象：

        当两个文件冲突时，git会为冲突的部分做标记，需要你手动选择需要保留的部分，然后手动删除标记信息和额外的信息再次提交。

查看主分支与其他分支的提交日志：git log –graph –abbrev-commit

合并策略

        合并的时候如果不发生冲突：

         合并不发生冲突的时候，也就是成功执行git merge后，git会自动提交一次，打印一下提交日志可以发现，只有一条单支线，分别不出我是单纯的做了一次提交还是合并时的提交。

        对比一下发生冲突后手动提交的日志：

        我们把上面正常合并后提交的日志记录模式叫做fast-forward模式，这种模式无法区分该次提交是在master分支正常提交还是合并提交，所以在企业开发中，我们一般不采取这种模式，而是这样：git merge –no-ff -m “提交信息” +分支名 

       

---

        在企业开发中，master主分支的代码一般是发行的代码，可以正常良好的运行，master分支的代码不能轻易修改，所以，我们对已发行的代码要进行更新通常的做法就是建立一个分支，在分支上修改提交代码，等到分支的代码测试以后无bug或者bug不影响功能运行时，我们才将其合并到master分支。当该分支出现在修改运行过程中又出现一个问题需要解决时，我们在主分支上再新建一个分支，用来解决bug，所以，git中，一个分支代表着一个开发场景或者特定的任务。

存储修改：git stash

        我们要对master代码进行更新，更新需要在一个分支上进行，创建一个名叫dev2的分支，在该分支上更新代码的时候发现一个bug（注意此时我们已经在工作区修改了部分代码但是没有提交），经验性的做法是要再从master分支上来创建一个专门修复bug的分支，bug修复好后与master分支进行合并：

        先创建一个dev2分支，模拟正在开发的场景：

        此时只是在工作区进行修改，没有add和commit，这个时候我们发现一个bug，我们再切换到master分支：

        git stash的作用就是，在分支的工作区进行修改时，修改完成后使用git stash，会保存你的修改，但是让代码保持你修改前的状态：

        同时看下.git仓库：

        这里会多出一个文件来保存做的修改。

        然后我们在master分支上再创建一个分支用来修复bug：

        修改完成后先在分支上提交，然后切回到主分支合并。这时就相当于你完成了bug修复

---

        这里需要指出，当你在某个工作区修改代码，修改完成后没有add也没有commit时，你这时切换分支，其他分支的工作区也会显示你修改的部分，当你在某个分支提交修改后，其他分支的工作区才保持修改前的状态。

---

 恢复修改：git stash pop

        修改完bug后，再回到dev2分支，你需要恢复之前的修改：

        可以看到，之前再dev2分支更新的代码恢复出来了。这个时候你需要提交一次，然后在与fix_bug,也就是修改bug的分支合并一次：

强制删除分支：git branch -D

        创建一个分支，如果该分支没有合并到主分支你就要删除它，git会给出提示不让你删除：

        使用上面的命令就可以强制删除：