Git用法指南(建议收藏)
一篇文章教你正确使用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 “描述” 合并的分支
开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！
更多推荐
12
0- 0
已为社区贡献1条内容
所有评论(0)