Git常用命令

1 初始化Git仓库

Git说白了就是一个版本仓库，每个版本都关联本地磁盘中具体的文件，那么如何将文件关联到仓库中呢。

（1）首先先进入本地磁盘文件目录

 （2）先使用git 仓库状态命令查看仓库情况

发现当前目录还不是git仓库

（3）执行git仓库初始化命令

Git  init 

 

（4）查看仓库状态 

 仓库中状态正常，没有任何文件

2 仓库文件管理初体验

（1）执行touch命令创建一个java文件

（2）查看新增文件的状态

Git status

 

 发现文件颜色是红色，且提示文件未被追踪，这里我们可以联想到之前讲git 仓库结构的时候有三个结构，分别是工作树，暂存区，目录，而这里TestGit.java文件就是还处于工作树中，根据提示可以知道，需要使用git add 命令将文件加入到暂存区。

（3）将文件加入暂存区

Git add TestGit.java

执行完命令后没有任何提示，没关系，我们使用git status查看下仓库中文件的状态

发现文件颜色有点绿，这里也意味着文件已经加入暂存区，根据提示我们可以知道可以通过git rm --calched 具体文件将文件从暂存区还原到工作树，这里就不操作了，大家有兴趣可以执行试试，然后查看文件状态是否还原。

（4）文件加加入git目录

Git commit -m”备注信息”

 

查看文件状态

 

 发现工作树中已经非常干净，都已经加入到git 目录当中，到这里我们已经初次完成了一个文件是怎么加入git 仓库的，过程分别是从工作树-暂存区-目录，对应的状态变化如下:

这上面涉及到了如下命令

Git add file 将文件加入暂存区
Git commit -m”commit memo” 将文件加入git 目录
Git status查看文件在仓库中的状态

 这里额外输出一个偷懒命令，因为每次对文件的操作都是从工作树-暂存区-目录，略显麻烦，如果想偷懒直接从工作树-目录，可以使用这个命令，这里需要特别注意，这个命令只针对之前已经加入过暂存区的文件有效，什么意思呢，如果是新增的文件，之前未执行过git add 命令加入暂存区，那么是无效的

Git commit -am”备注信息”

 比如，我们先使用vi TestGit.java修改之前已经加入过暂存区的TestGit.java文件

 

然后执行git commit -am”跳过暂存区”看下效果 

 

发现修改内容直接提交到了目录。

我们再尝试一下新增文件是否有效

新建一个Temp.java文件

 执行git commit -am”提交测试”

 发现无法commit，所以偷懒命令的使用是有范围的。

3 查看提交历史

最原始的历史提交查看命令是git log

为什么说原始，就是因为信息太多，不方便阅览

简化高效版命令，也是工作中推荐使用的是下面这个组合命令

Git log --oneline --graph

 

 

--oneline 是多个命令--pretty=oneline --abbrev-commit的缩写，这个命令不仅简化了历史版本的信息输出，同时将SHA-1的散列值也简化成了前8位，方便查看版本信息和对比，在工作中使用这个命令可以解决大多数问题，而--graph则是视图优化，以ASCII 图表来显示分支和合并历史。

因为还没讲到分支合并，这里我们只进行命令演示

4 撤销操作 

在前面已经提到了三个区域，分别是工作树，暂存区，目录，其分别对应了不同的git命令,git add/git commit 来完成文件在区域中的移动，既然有前进，那么就一定有后退，那么怎么将修改文件还原，怎么将提交到暂存区的文件退回工作目录呢？

（1）取消已经修改的内容

当我们在工作树当中修改了某个文件，但是后面想还原成修改之前的内容，可以通过git checkout -- 文件名来完成，如下，我们在工作树当中修改Temp.java文件

 

然后我们发现修改的内容不对，不想要了，想还原成修改之前的内容，

执行git checkout -- Test.java

 

发现内容已经还原

（2）取消已经提交到暂存区的内容

当我们把文件修改完并且已经提交到暂存区，但是发现内容需要再进行调整，可以通过git reset head 文件名完成

我们可以先在Temp.java文件当中修改内容并提交到暂存区

 

然后执行git reset head Temp.java完成暂存区回退

 

这个时候可以发现，文件已经回到工作树修改的内容，完成回退

5 git分支 

什么是分支，在日常研发流程当中，代码不是从0到1的过程，而是基于现有代码进行编辑，那么现有代码我们可以看成一个基础分支，如果这个时候来了A和B两个需求，分别都要对基础分支进行修改，那么就可以基于基础分支，分别拉出两条开发分支

 （1）创建分支

 基于master分支创建一条开发分支rel_A

Git checkout -b rel_A

可以发现我们的分支名已经发生了变化，从master变成了rel_A

（2）切换分支

如果这个时候我们又想回到master分支，怎么办呢？

可以通过git checkout master命令来进行切换

 这个时候发现分支已经切换回来了

（3）分支合并

当我们开发分支完成变更后，往往需要进行代码合并，因为很有可能是和团队一起进行的迭代开发，这里面就需要所有参与者将代码合并到一个分支当中，形成完整的功能代码，那么怎么合并呢，这里说一下命令，但是在实际工作当中不常用，一般使用图形化工具

首先我们通过git checkout rel_A回到开发分支，然后进行修改并提交

然后切换回master分支，进行代码合并，查看合并结果 

 

发现在分支rel_A添加的内容在master中已经存在了，说明我们已经将分支合并到master

（4） 合并冲突解决

在多人合作开发场景下，代码冲突是无法避免的事情，发生的原因很简单，就是大家对同一个代码进行了修改，然后在合并的时候git不知道采用哪一个修改，也就是出现冲突，需要人为的解决，下面使用命令行进行演示，实际开发过程中使用图形化工具要方便得多

首先，我们分别从master分支切换出两个开发分支dev_A和dev_B，然后分别对Temp.java文件进行编辑，最后再将两个分支合并进入master，看看会有什么效果。

先拉分支dev_A，并修改文件

 

再拉分支dev_B，并修改文件

 

 

最后，我们切换回master，并分别将dev_A和dev_B合并到master分支

先合并dev_A

发现没有任何问题，合并成功，再合并dev_B试试

 

合并失败，出现冲突，怎么解决这个问题呢

进入Temp.java文件的编辑界面，发现出现了master分支和dev_B分支冲突的内容

要解决冲突，首先需要知道我们需要那个版本的代码，如果是维持master代码，我们只需要将dev_B的代码删除就好，当然，这里面的分隔符>>>>>也要删除，如果都需要，也可以都保留，看实际需要，这里我们都保留，进行编辑并保存

 

保存后，查看状态

发现还是处于conflicts，不着急，我们进行提交即可

 

通过查看状态，发现冲突已经解决，到此，文件完成合并

（6） 删除分支

Git branch -d 分支名