十分钟了解 git 那些“不常用”命令

点击上方“Java之间”，选择“置顶或者星标”

你关注的就是我关心的！

来源：SegmentFault 社区

上一篇：SQL的各种连接Join详解，都需要熟练掌握！

本文主要是介绍 git 不常用初期不太会用的命令，希望你看了能理解这些命令的使用，并在平时使用过程中一点点地刻意进行练习，逐步熟练并知道何时需要用到这些命令去解决你的问题。

基础命令

如果你还是刚刚接触 git 命令，还不清楚仓库、工作流、分支、提交的童鞋可以先看下 git 使用简易指南，这个应该是我初学 git 看的第一份且收藏至今的指南了~ 图解很清晰易懂，真 10 分钟入门的资料

git 使用简易指南:
https://www.bootcss.com/p/git-guide/

然后你会发现如下基础命令将会成为你之后几乎每天都要用到的 80% 的命令：

• git clone git@github.com:nohosts/nohost.git 克隆远程仓库的内容到本地

• git pull origin master 获取远程分支 master 并 merge 到当前分支

• git branch -a 查看全部分支（远程+本地）

• git checkout -b bugFix 新建 bugFix，并切换到到此分支。（如果分支已存在则去掉-b即可）

• git status 查看当前~~~~版本状态（是否修改）

• git add . 增加当前子目录~~~~下所有文件更改至暂存区

• git commit -m 'xxx' 提交暂存区的修改至本地的版本库, 修改备注为xxx

• git push 将本地版本推送到远程分支

• git tag v1.0 dfb02e6e4f2f7b573337763e5c0013802e392818 增加 v1.0 的 tag 到某个提交上

• git merge testBranch 合并 testBranch 分支至当前分支`

• git stash 暂存本地的当前修改，将本地代码重置为 HEAD 状态。（如果需要取出修改，命令后加一个pop即可）

• git log 显示提交日志（如果想每个提交信息显示在一行，可以加上--pretty=oneline）

• git show dfb02e6e4f2f7b573337763e5c0013802e392818 显示某个提交的详细内容

• git reset --hard HEAD 将当前版本重置为 HEAD

注意这两个命令的区别：


git pull = fetch + merge

git pull --rebase = fetch + rebase



"不常用"命令

一、git rebase 变基

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。——git-scm 变基

说明：后面的举例每个分支都有不同的颜色，*前缀表示现在所处的分支，而 commitid 都由 C0、C1、C2 代替每一个提交的哈希值，箭头表示分支的继承。

我们之前整合分支用的最多的就是 merge 了，那 merge 和 rebase 有什么区别呢？

1. merge

merge 合并两个分支时会产生一个特殊的提交记录，它有两个父节点。简单说就是：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

git checkout master; git merge bugFix

下图中左、右两张图分别是执行如下代码前后的样子：

可以看出来，红色圈圈是最主要的改变—— merge 合并分支后，会在 master 分支上新增一个 C4 提交，而 C4 提交里面有 master 和 bugFix 代码库所有的修改。

此时的 bugFix 代码还没和 master 同步（颜色不同），我们还需要执行如下代码：


git checkout bugFix; git merge master

2. rebase

rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。它的优势就是可以创造更线性的提交历史。

git checkout bugFix; git rebase master

下图中左、右两张图分别是执行代码前后的样子：

bugFix 分支里的内容通过 rebase 直接复制到 master 分支上。现在 bugFix 分支上的工作在 master 的最顶端，同时我们也得到了一个更线性的提交序列。

注意：提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 rebase 到 master 分支上的 C3 的副本（内容是一样的，只是 commitid 更新了）。

但是，此时 master 还没有和 bugFix 同步（颜色不同），我们还需要执行如下代码：

git checkout master; git rebase bugFix

由于 bugFix 继承自 master，所以 Git 只是简单的把 master 分支的引用向前移动了一下而已。

3. rebase 的延伸用法

3.1 省去切换分支即可 rebase


git rebase targetBranch originBranch

表示切换到 originBranch，然后执行 git rebase targetBranch

3.2 修改某几次提交

git rebase -i commitid

如上图标注的，传的 commitid 为你想修改的提交的前一个 commitid。执行命令后进入 vi 模式，会提示你一些操作命令（p、r、e...）你只需要在最上方修改默认的 pick 为你想要的操作，然后退出并 wq 保存即可生效。

具体操作：

• pick 使用（啥也没变）

• reword 使用并修改 commit msg, 改后 commit id 也会更新

• edit 使用并编辑 commit 时的文件
• 编辑后 git add . 然后 git commit —amend 还可以更新最新的 commit msg。git rebase —continue 把后面的内容加进来并解决冲突, 最后提交。最新的 commit id 也更新

• squash 合并 commit

选择最新的 commit 去合并，然后 continue 发现这一次和上一次的 commit msg 都有，你可以删除只留下想要的也可以进行修改然后 continue 和 push。如果你不删的话会发现全部文本行都组成了一个多行的 commit msg
如果 commit 再往前已经没有了就不能再 squash，否则会报错（ error: cannot 'squash' without a previous commit ）。然后 git rebase --edit-todo 可以继续 vi 编辑

• fixup 合并 commit 到前面而且 commit，commit msg 也没了

• drop 删除某个 commit

注意：

如果想要恢复这一次 rebase 操作，则可以执行 git rebase —abort。

如果想完全恢复本地分支到远程的状态，可以执行 git reset --hard origin/bugFix ，或者你可以 git reflog 找到对应提交记录回滚，但是有点麻烦。

4. rebase 需要谨慎使用

当你要改写的 commit history 还没有被提交到远仓库的时候，也就是说，还没有与他人共享之前，commit history 是你私人所有的，那么想怎么改写都可以。

而一旦被提交到远程后，这时如果再改写 history，那么势必和他人的 history 长的就不一样了。git push 的时候，git 会比较 commit history，如果不一致，commit 动作会被拒绝，唯一的办法就是带上 -f 参数，强制要求 commit，这时 git 会以 committer 的 history 覆写远程分支，从而完成代码的提交。虽然代码提交上去了，但是这样可能会造成别人工作成果的丢失，所以使用 -f 参数要慎重。

所以，在不用 -f 的前提下，想维持树的整洁，方法就是：在 git push 之前，先 git fetch，再 git rebase。

5. 总结

• 无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

• 在你自己的分支（非他人共享）的分支进行 rebase 是可以的，但是如果在公共分支 rebase 修改提交需要谨慎——最好是先 fetch、再 rebase、最后 push。

二、git cherry-pick 选择

cherry-pick 可以将提交树上任何地方的提交记录取过来追加到 HEAD 上（只要不是 HEAD 上游的提交就没问题）。

git checkout master; git cherry-pick C2

下图中左、右两张图分别是执行代码前后的样子：

是不是有点眼熟:D 没错这个和 rebase 的效果蛮像的，这两个命令都可以实现复制提交~

三、git reset VS revert 回滚

git revert HEAD 是用一次新的 commit 来回滚之前的 commit，git reset 是直接向上移动分支，删除一些 commit 看上去像从未提交一样。这两者看似达到的效果是一样的，其实完全不同。

git reset HEAD~1

git revert HEAD

如下所见，图 1 是初始状态（需要撤回 C2 提交），图 2 和图 3 是从图 1 分别执行 reset 和 revert 后的结果：

• reset
执行后，master 分支移回到了 C1；现在我们的本地代码库根本就不知道有 C2 这个提交了

• revert
执行后，在我们要撤销的提交记录 C2 后面多了一个新提交 C2'，而 C2' 引入了更改—— 这些更改是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。

注意：

• 如果你已经 push 到线上代码库, reset 删除指定 commit 以后, 你 git push 可能导致很多冲突.但是 revert 并不会。

• 如果此回退的分支合并主干分支时，reset 恢复部分的代码依然会出现在历史分支里，但是 revert 方向提交的 commit 并不会出现在历史分支里。


# 事例
reset后的123 merge了12345 还是12345
revert后的12345(-3) merge了12345 是12345(-3)

四、HEAD^n 和 HEAD~n 相对引用

HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。HEAD 总是指向当前分支上最近一次提交记录

(如果想看 HEAD 指向，可以通过 cat .git/HEAD 查看，如果 HEAD 指向的是一个引用，还可以用 git symbolic-ref HEAD 查看它的指向。)

1. 基础使用：

• 使用 ^ 表示向上移动 1 个提交记录。
n 表示第 n 个父提交，不填默认是 1(正上方)

• 使用 ~ 向上移动多个提交记录
如 ~3

注意：操作符还支持链式操，如 HEAD^2~3^

2. 延伸用法：

移动分支：可以直接使用 -f 选项让分支指向另一个提交。例如下面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。

git branch -f master HEAD~3

这次主要就总结了这几种“不常用”git 命令，希望大家和我都可以多多练习，让他变成你需要时就可以自如使用的“常用”命令！

最近热文阅读：
1、SQL的各种连接Join详解，都需要熟练掌握！
2、IDEA真牛逼，900行"又臭又长"的类重构，几分钟搞定
3、IDEA新特性：提前知道代码怎么走！
4、一款SQL自动检查神器，再也不用担心SQL出错了，自动补全、回滚等功能大全
5、MySQL：互联网公司常用分库分表方案汇总
6、Mybatis：颠覆你心中对事务的理解
7、SpringBoot实现通用的接口参数校验
8、用好Java中的枚举，真的没有那么简单！
9、强软弱虚引用，只有体会过了，才能记住
10、吐血整理！14 个 Spring MVC 顶级技巧！
关注公众号，你想要的Java都在这里