Git命令操作总结

原创作品，如需转载，请注明来源

推荐参考廖雪峰的git教程

准备：

相关安装不再赘述，首先码云上要准备一个远程仓库用来管理我们所有的记录，这里我定义的远程仓库是GitLearnning，配置好相关私钥公钥以后，

然后在本地新建一个GItLearnning文件夹作为工作区，然后进入git命令行编辑模式，执行初始化命令

git init

于是在我们GitLearnning这个文件夹下就会出现一个.git的隐藏文件夹，这个隐藏文件夹就是我们的本地仓库

关于Git的工作区，本地仓库，远程仓库，还有缓存区可以依靠下面这张图来很好的理解

我们平时做的修改首先需要通过add命令添加到缓存区，然后再通过commit命令才算真的提交，Head是一个指针，代表当前所在的分支，master是我们的主分支，当我们第一次建立版本仓库时，

git会自动为我们建立master这个分支，用一个hash码来标记版本。之后我们每一次提交修改，都会生成一个新的hash码，并且Head指针指向下一个版本。Head指向哪个分支，哪个分支就是当前分支。

 

 

现在我们模拟修改提交

先创建两个文件：git1.txt git2.txt

分别添加两句话，这是第一个git文件，这是第二个git文件

提交文件到仓库分为两步：add和commit

1.add

$ git add .

此时使用git status 可以查看状态

发现已经有两个新文件进入了缓存区，但是还没有提交

2.commit

$ git commit -m 'first'

提交成功

需要注意的是，对于add命令需要指定提交到缓存区的文件名字，如果全部提交可以使用 .

对于commit命令需要加上提示信息，上面我们为第一次提交的提示信息，first

 

提交到远程仓库

首先我们需要从码云上建立的远程仓库上获取一个地址

然后在我们的命令终端创建远程仓库连接

$ git remote add origin git@gitee.com:re-startyang/GitLearnning.git

这条命令的意思是创建一个名为origin的远程仓库连接地址

在使用时，请根据自己实际码云项目地址使用

紧接着我们要先从远程仓库拉取文件，因为在创建远程仓库时我使用了readme.md文件，如果不拉取直接提交将会拉取不成功

错误案例如下：

它在提示你，push不成功，因为远程仓库包含你现在本地没有的文件，那可能是因为其他仓库提交的文件，

对于这种情况，当然有强制提交的命令，但是不推荐，如果远程冲突，解决起来相当麻烦

我们还是按正常逻辑来，先去pull

$ git pull origin master

这段命令行的意思是，从origin这个远程仓库的master分支上拉取文件

执行结果：

然而即使这样我们发现仍然没有从码云上成功拉取我们要的文件，这是因为远程仓库的origin分支和master和本地仓库分支master被git认为是不同的仓库，不能直接合并

需要一行特殊的命令处理来忽略这个差异（因为我们远程仓库只有一个readme.md文件，所以这种做法是安全的）

$ git pull origin master --allow-unrelated-histories

执行结果：

这样就成功把码云上的readme.md文件拉取下来了。

其实如果想规避上边这种问题也很简单，出现问题的原因是因为我们在从远程仓库拉去之前工作区内容已经commit到本地仓库，如果我们先从远程仓库拉取然后再心间git1.txt,git2.txt并add和commit,就不会出现这种问题

推送到远程仓库

$ git push origin master

执行结果：

 

版本回退

首先再新建一个git3.txt文件，然后里边写一句话，这是第三个git文件

之后执行add,commit

使用命令获取提交日志

$ git log

可以看到每次提交都产生了新的hash码，并且Head指向了最新的master分支，如果我们想要会退到某个版本只需要通过指定目标版本的hash码，并且这个hash码并不需要写全，一般写六位就可以了

执行命令，会退到67133e077130085b89c5203c8d0ce65cd851f7ed这个版本

$ git reset --hard 67133e

执行结果:

版本已经回滚，并且之前那条日志也没了，再看我们的工作区

git3.txt已经不存在了

 

撤销修改

撤销修改有两个情况需要考虑：

1.修改了，但是还没有add到缓存区

2.提交到缓存区了，又进行了修改

分别来模拟下这两种情况，首先第一种，

我们打开git2.txt这个文件在里边添加一句话：这是修改

此时查看状态：

这时我们还没有提交但是不想要这个修改了，执行命令：

$ git checkout -- git2.txt

再打开git2.txt这个文件发现它里边已经没有

 

接下来再来模拟在已经提交到缓存区的情况下修改撤销

仍然现在git2.txt中添加文字：这是修改

然后提交到缓存区

然后再次添加一行：又一次修改

这时你说这个修改你不想要了，想会退到之前那个add后的版本，执行命令

$ git checkout -- git2.txt

add后又修改的内容就不见了

 

切换分支

在git中记录的只是修改而不是具体内容，HEAD不指向提交，master才指向提交，Head只指向master

所以当我们需要一个新的分支的时候只需要将HEAD指向新的分支就可以了

创建分支dev

$ git branch dev

查看所有分支

$ git branch

结果

可以看到我们现在有两个分支，一个master,一个dev

切换分支：

$ git checkout dev

新建一个dev.txt文件，然后add,commit

之后我们切换回master分支，发现dev.txt并不存在，因为它是在dev这个分支出现之后才出现的，如果在dev的基础上再切出新的分支，才可以带着dev.txt

 

分支合并

$ git merge dev

把dev分支合并到当前分支上

合并之后，删除掉原来的分支dev

$ git branch -d dev

 

这里有一种特殊的情况，就是假如我们从master这个线上分支切出来一个分支dev1作为下一阶段要开发的版本，突然告诉你线上版本有个紧急bug需要修复，如何在不影响现在开发进度的基础上去处理这种情况？

通用做法是先从master分支上切出来一个新的分支dev2,在这个dev2上进行修改，然后合并到master上。

让我们模拟一下：

首先创建一个分支dev1,然后切换过去，修改我们的git2.txt,添加一句话，这是dev1修改的

此时master出现了bug,我们需要先从master上切出来dev2这个分支，但是问题来了，直接从dev1切回master

我们会发现在master分支的文件夹中也有我们修改过的git2.txt

如果此时提交，master也会有这个修改过的git2.txt

假如这个文件我们根本就没写好，甚至还带着错，这样提交显然会让master崩坏掉，是极不安全的。

这种情况下我们有两种解决方法：

1.dev1分支下add commit,在切换回master,此时就不会在master中看到被修改过的git2.txt。缺点就是你仍然要保证commit的代码没问题。

2临时保存dev1这个分支的内容,然后切回master,等修改完bug之后再回来仍然使我们正在改的状态


$ git stash

此时再切换回master发现git2.txt是未被修改的。

然后再切换回dev1,嗯，之前写的都没了，。。。炸锅。先别急，git只是给你把那些东西先存放在一个地方了，你仍然找得到

$ git stash pop

找回我们之前stash的内容，并把那个stash删除掉，于是你又可以看见自己辛辛苦苦写的代码回来了