【整理】不熟悉的git命令

虽然百分之80的情况下在使用百分之20的命令，如 git add /git commit/git pull/git push/git clone/git status/git branch。但是遇到稍复杂的情况就搞不定，有必要弄明白一些场景下不熟悉的git用法。

rebase、cherry pick、stash、reset –Hard等等什么场景下用. （有些仍然没有看懂，需要再使用和重新整理。）
现记录如下：

“合并冲突

“提交到了错误的分支

1.使用rebase推送而非merge

如果您正在团队中工作并且整个团队都在同一条branch上面工作，那么您就得经常地进行fetch/merge或者pull。Git中，分支的合并以所 提交的merge来记录，以此表明一条feature分支何时与主分支合并。但是在多团队成员共同工作于一条branch的情形中，常规的merge会导致log中出现多条消息，从而产生混淆。因此，您可以在pull的时候使用rebase，以此来减少无用的merge消息，从而保持历史记录的清晰。
$ git pull –rebase
您也可以将某条branch配置为总是使用rebase推送：
git config branch.BRANCH_NAME_HERE.rebase true

分支合并会被记录为一次合并提交，这种做法是很有意义的。比如说，可以通过这种方式来标识一个新特性被合并到了发布分支中。不过，当多个团队成员工 作在一个项目中并使用常规的git pull来同步分支时，提交时间线就会被不必要的合并提交所污染。更好的做法则是使用git rebase将一个feature分支变基到master分支：
gitcheckoutfeature git rebase master
这么做会将整个feature分支移动到master分支的起点，它会合并master分支上所有新的提交。不过，相比于使用合并提交来说，变基会 通过在原来的分支中为每次提交创建全新提交来重写项目历史。变基的主要好处在于你会得到一个更加整洁的项目历史。此外，这里还有关于变基的陷阱的一些讨 论。

merge和rebase的区别是，merge会尝试解决改动并创建的新的提交来融合他们。rebase则是将从你最后一次从另一个分支分离之后的改动并入，并直接沿用另一个分支的head指针。

如果你不能确定哪个分支（哪些需要合并，哪些需要移除）。这里有两个git分支切换方式来帮助你：

Shows branches that are all merged in to your current branch
$ git branch –merged

Shows branches that are not merged in to your current branch
$ git branch –no-merged

2. 在执行git rebase后解决合并冲突

正如能力越大责任就越大一样。在执行git rebase时，你可能会遇到合并冲突的情况。合并冲突表示两个提交修改了同一个文件的同一行，Git不知道该应用哪一个修改。这会导致如下所示的错误消息：

Git会为你提供3个选择来修复导致冲突的提交（fa39187）：

• 可以运行git rebase –abort来完全取消变基。这么做会取消变基修改，并将分支置回到执行git rebase之前的状态。
• 可以运行git rebase –skip来完全忽略该提交。这样，有问题的提交所引入的变化就不会被添加到历史中。
• 可以使用与合并冲突相同的标准步骤来解决冲突。

3. 临时性保存修改（stash的用法）

在工作进行中时，有些东西常常会处于凌乱的状态。如果这时需要切换到不同的分支该怎么办呢？Git是不允许你这么做的，因为还有尚未保存的修改。坦 率地说，你并不想将半成品提交上去，后面再来修改。这个问题的解决之道就是使用git stash命令。Stash会接收工作目录的当前状态（比如说，修改了的追踪文件与暂存区的修改等），并将其保存到未完成的修改栈中，这样后面随时可以再 来修改。可以通过如下命令来暂存你的工作：

$ git stash
Saved working directory and index state WIP on feature: 3fc175f fix race condition
HEAD is now at 3fc175f fix race condition
现在，工作目录就是干净的了：

$ git status
On branch feature
nothing to commit, working directory clean
这时就可以安全地切换分支做别的事情了。不过不必担心，暂存的提交依旧还在：

$ git stash list
stash@{0}: WIP on feature: 3fc175f fix race condition
稍后，在回到feature分支后，你就可以取回所有暂存的变更了：

$ git stash pop
On branch feature
Changes not staged for commit:
(use “git add …” to update what will be committed)

 modified:   index.html

Dropped refs/stash@{0} (ac2321cc3a33ba712b8e50c99a99d3c20da9d6b8)
关于暂存，还有其他一些选项可用，如下所示：
git stash save “describe it”   # give the stash a name git stash clear # delete a stashed commit
$ git stash save –keep-index # stash only unstaged files

5. 将cherry-pick远程提交合并到自己的分支中

更有甚者，如果只想将远程仓库的一个特定提交合并到自己的分支中该怎么做呢？可以使用git cherry-pick 来选择给定SHA值的提交，然后将其合并到当前分支中：

$ git cherry-pick

5. 检测 你的分支的改变是否为其它分支的一部分

cherry命令让我们检测你的分支的改变是否出现在其它一些分支中。它通过+或者-符号来显示从当前分支与所给的分支之间的改变：是否合并了(merged)。.+ 指示没有出现在所给分支中，反之，- 就表示出现在了所给的分支中了。这里就是如何去检测：
git cherry -v OTHER_BRANCH_NAME_HERE
//例如: 检测master分支
git cherry -v master

7. 忽略追踪文件中的变更

如果您正在一个团队中工作，而且大家都在同一条branch上面工作，那么您很有可能会经常用到fetch和merge或是git rebase。但是有时候这样会重置您的环境配置文件，如此的话，您就得在每次merge后修改它。使用这一命令，您就能要求git忽视指定文件的变动。这样，下回你再merge的话，这个文件就不会被修改了。
git update-index –assume-unchanged PATH_TO_FILE_HERE

10. 清理

有时，Git会提示“untracked working tree files”会“overwritten by checkout”。造成这种情况的原因有很多。不过通常来说，我们可以使用如下命令来保持工作树的整洁，从而防止这种情况的发生：

git clean -f     # remove untracked files git clean -fd # remove untracked files/directories
$ git clean -nfd # list all files/directories that would be removed

11. 将项目文件打成tar包，并且排除.git目录

有时，你需要将项目副本提供给无法访问GitHub仓库的外部成员。最简单的方式就是使用tar或zip来打包所有的项目文件。不过，如果不小心， 隐藏的.git目录就会包含到tar文件中，这会导致文件体积变大；同时，如果里面的文件与接收者自己的Git仓库弄混了，那就更加令人头疼了。轻松的做 法则是自动从tar文件中排除掉.git目录：

$ tar cJf .tar.xz / –exclude-vcs

9.检查提交的变动是否是release的一部分

name-rev命令能告诉您一个commit相对于最近一次release的位置。使用这条命令，您就可以检查您所做出的改动是否是release的一部分了。
$ git name-rev –name-only COMMIT_HASH_HERE

查找问题的利器 - Git Bisect

gitbisectstart git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on S

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

$ git bisect reset

$ git bisect visualize

$ git reset –hard fb47ddb2db…

查找问题的利器 - Git Blame

Git Hooks

钩子(hooks)是一些在”$GIT-DIR/hooks”目录的脚本, 在被特定的事件(certain points)触发后被调用。当”git init”命令被调用后, 一些非常有用的示例钩子文件(hooks)被拷到新仓库的hooks目录中; 但是在默认情况下这些钩子(hooks)是不生效的。 把这些钩子文件(hooks)的”.sample”文件名后缀去掉就可以使它们生效了。

applypatch-msg

GIT_DIR/hooks/applypatch-msg

[1].你需要知道的 12 个 Git 高级命令, 2016年01月31日
[2].10个很有用的高级Git命令, 2013年08月23日
[3].Git中文手册 – 高级用法, 2013年04月06日