Git用法指南(建议收藏)

       🔥🔥 欢迎来到小林的博客！！
      🛰️博客主页：✈️林 子
      🛰️社区 :✈️ 进步学堂
      🛰️欢迎关注：👍点赞🙌收藏✍️留言

创建仓库

命令：git init 使用后会在当前目录创建一个.git文件。

仓库配置

仓库创建完之和，我们还需要配置name和email信息。

当前仓库配置命令：

git config user.name "your name" 引号处填你的git用户名

git config user.email"your email" 引号处填你的git邮箱

执行结果：

我们就会发现user.name和user.email配置成我们自己的了。

那么我们想修改怎么办呢？

我们可以用git config --unset user.name/email 来重置配置。

这样我们的user.name 和 user.email就被重置了。

但是如果我们想要当前机器上所有的仓库都配置，而不是仅仅只配置一个。那么我们可以用全局配置命令。

全局配置命令：

git config --global user.name ”your name“

git config --global user.email”your email“

而全局配置是无法用局部配置删除的。例如：

全局变量删除：

git config --global --unset user.name

git config --global --unset user.email

文件提交

git文件提交是先将工作区的内容添加进暂存区，随后从暂存区上传至本地仓库。

工作区：就是你当前仓库下非.git/文件夹的区域。

暂存区：git add后，文件暂存的区域。

本地仓库：git commit 后，将暂存区域的文件提交到本地仓库。

命令：

git add 文件名/. 文件名是添加单个文件至暂存区，.是添加当前目录所有文件至暂存区。

git commit -m "提交描述" 提交描述要描述文件提交的一些细节。

我们touch一个文件ReadMe，并在里面写上hello git。

这样我们的文件就提交成功了，如果有提交到远程仓库，那么可以用git push命令，具体操作可以看我之前写的博客 git提交三把斧

版本回退

什么是版本回退呢？

就比如你写了一个文档，第一次提交为v1版本，第二次提交为v2版本。当我们提交到v20个版本的时候，突然想回到第10个版本。这就是版本回退，而git里面有一个objects对象来存储每次修改后的版本。

版本回退的命令：

git reset [--soft | --mixed | hard] [head]

--soft选项只会回退版本库，而不会回退暂存区和工作区。

--mixed则会回退版本库和暂存区，不回退工作区，如果选项不填，该选项为默认选项。

--hard 工作区，暂存区，版本库统统回退。如果此时你工作区写了新的数据还没来得及提交，那么该选项会让你的v10版本后写的代码统统消失！所以该选项请慎用。

我们用v20来描述当前版本，v10来描述回退版本。

工作区	暂存区	版本库	回退选项
v20	v20	v10	–soft
v20	v10	v10	–mixed(默认)
v10	v10	v10	–hard(慎用)

接下来我们用–hard选项来演示一下版本回退。

我们先往ReadMe里面添加一行hello world，然后提交，更新至版本v2

然后我们再创建2个文件 file1 和 file2，再次提交，更新至版本v3

现在我们的目录下是有三个文件的，分别是file1，file2 和 ReadMe。

然后我们用命令 git log --pretty=oneline 来查看之前的提交信息。

前面那一串是用哈希计算出的一串16进制数字，它对应的是每一个回退的版本，回退版本存储在objects文件夹中。

而我们要回退哪个版本，就输入哪个版本即可。

我们输入 git reset --hard 182eaf20b1263fa1a548ca946af9eb53f514f805 回退到v1版本。

然后我们就发现，我们的目录只剩下一个文件，并且该文件的内容是hello git。说明我们的版本成功回退到了v1版本。 用–hard选项只是为了直观的演示回退效果，实际运用中用hard的话，你的工作区内容就会被覆盖掉。那么你之后写的代码也就没有了。

如果这时候右想回退回去呢？ 我们用 git reflog 来查看一下历史输入的指令。

然后输入 git reset --hard 93c817a 回退回去即可。

注意！ reflog只显示最近几条的提交记录，也就是说有可能会被覆盖掉。那么到时候就无法回退了。

小问题：为什么回退版本会这么快？

这是有一个HEAD指针指向master，而master则是存储的对象id(就是上面回退时所用的一串16进制数字)。

我们查看一下master里面的内容，就能看见它实际只是存储了一个对象id，这个对象id对应着objects里面存储的版本对象。

撤销修改

当我们写着写着发现自己写的代码太垃圾了，想撤销掉修改怎么办？

我们分三种情况来讨论：

第一种情况：写的代码还没有上传至暂存区，只在工作区中。

这种情况我们可以直接对文件修改，删除文件代码，但是这种方法不推荐。一是删除效率很慢，二是如果删错了可能会让代码产生bug。

第二种方法则是用命令： git checkout -- 文件名 来对问进行回退。

我们先给ReadMe随便加上一行数据，然后用命令对它进行回退。

回退成功！

第二种情况：写的代码已经上传到了暂存区，但还没提交到版本库。

第二种情况就是文件在工作区和暂存区，但是还没有提交到版本库。那么我们可以使用上面说过的reset选项来回退到当前版本，你没听错，reset是可以回到当前版本。我们用 reset --mixed可以把暂存区和版本库都回到当前版本，这时候就转换成了第一种情况，我们在用checkout – 来回退文件版本。

接下来我们演示一下：

我们先在ReadMe文件下面新增一行，然后把它添加进暂存区。

然用 git reset HEAD 回退到当前版本, HEAD指当前版本。

然后我们发现它提示我们暂存区没有可以提交的文件，这时候我们就可以当作第一种情况来处理，回退ReadMe文件。

输入 git checkout -- ReadMe 回退

回退成功！

第三种情况： 写的代码上传到了暂存区，并且还提交到了版本库。

第三种情况就是我们的代码已经提交到版本库了。也就是当前版本下是包含了xxxx code代码的，那么上一个版本肯定就是没有包含xxxx code代码的。那么我们只需要回退到上一个版本即可。

该情况回退有一个前提！ 那就是该仓库还没有push至远程仓库！

演示：

先添加一行xxxx code，然后添加至暂存区，上传至版本库。

然后用 git reset --hard HEAD^ 回退，HEAD^{表示上一个版本，HEAD}^表示上上个版本，以此类推。

回退成功！

文件删除

当我们的文件已经上传到了版本库种，如何删除它呢？

我们可以使用 git rm 文件名 来删除，之和在git commit -m 来提交变动即可。

分支管理

分支就类似于支线任务，主支则是master。分支就是master的分身，分支做的事情最终都可以合并到master种。

打个比方：master的任务是练习葵花宝典，而练习葵花宝典需要五天。如果此时master想在五天内同时练习葵花宝典和辟邪剑法。那么它可以开一个分支，让分支去练辟邪剑法，自己练葵花宝典。五天后让分支合并过来，那么此时的master就既会葵花宝典，也会辟邪剑法。

创建分支

我们可以用git branch name 来创建分支 。

也可以用 git branch 来查看分支。

切换分支

我们可以用git checkout 分支名 来切换分支。

合并分支

我们要知道.git/HEAD 指针指向的就是一个分支，也就是说，HEAD指向哪个分支，那么你上传就会上传到哪个分支。

我们切换到到dev分支。

随后我们修改ReadMe里的内容并上传到版本库。

这时候我们在dev分支内查看ReadMe的内容。然后在切换到master分支查看内容，我们会发现master还停留在之前的版本。

而我们再对照一下 .git/refs/heads目录下dev和master的内容。

我们可以发现它们记录的提交版本是不一样的，简单来说就是master分支停留在之前的版本。这时候我们就可以合并分支。

合并分支命令：git merge 分支

我们合并分支后就会发现ReadMe更新了。

我们再来看看heads目录下两者的最新提交版本信息。

可以发现它们的提交版本是一样的。所以所我们的分支合并是非常快的，因为它只需要修改 ./git/refs/heads/master 中的提交版本即可。

删除分支

删除分支命令： git branch -d 删除的分支名

不过删除分支要注意的一点是，不能在当前分支下删除当前分支，只能在其他分支下删除你要删除的分支。

所以我们切换到master分支后，即可删除分支。

然后我们就成功删除了dev分支。

有时候 git branch -d 删除的分支名 可能会不成功，此时我们用 git branch -D 删除的分支名 即可进行强制删除。

合并冲突

当我们的分支和master同时修改了该文件时，那么此时合并就会发生冲突。

此时我们的ReadMe内容是这样的：

首先我们创建一个分支dev1，然后把ReadMe的最后一行修改为bbbb code。

然后add -> commit -m 更新

然后我们切换回master分支，把ReadMe修改为cccc code。

然后master也 add -> commit -m 提交

然后我们合并分支

然后就提示我们在ReadMe内有一个冲突，并让我们修复冲突后重新提交结果。

那么我们打开ReadMe文件修复一下冲突。

我们就发现 了一些奇怪的东西， HEAD -> ====区间是当前master的内容， 剩下的是dev1的内容。意思就是让你选择其中一个分支的内容，我们选择bbbb code，那么就把其他的删除掉。

然后保存退出，并且重新提交一次。

此时我们的冲突就修复成功了。

我们再来看看dev1和master的最近一次提交。

我们会发现不一样，因为master后面解决合并冲突时又重新提交了一次。我们可以输入git log --graph --abbrev-commit 来查看提交日志。

此时我们就能清除的看到，master的最新提交为什么和dev1的不一样。

而以上的合并模式是fast forward模式，我们也可以使用非fast forward来合并

命令：git merge --no--ff -m “描述” 合并的分支