个人总结出的一些实用的 git 命令，分享给大家。
git config --global color.ui true
让 git 命令默认使用彩色输出。 这条命令在 git 2 之后已经成为默认配置，但如果你还在用比较老的版本（例如 CentOS 上的默认的 git 版本），建议把这项配置加上去。
git branch -av
显示所有本地即远程分支，并显示最后提交的 Commit 信息。如果不加参数，则只会显示所有本地分支的名字。
git checkout -b <NAME> [<START POINT>]
创建，并切换到新分支。git branch <NAME> 只会创建分支而不会切换到新分支，可以用它备份当前分支。
git tag -L <PATTERN>
列出所有符合条件的标签。如果你的项目严格按照 Major.Minor.Update 作为版本名称，那么这条命令就非常有用。它可以直接列出来当前版本下有那些小的 bugfix 版本。当然如果你非要 grep 一下我也没意见。
git diff -w
显示未提交的更改，忽略空格。人们往往注重实际代码的改变而不注重缩进的变化。如果某个文件有大量缩进改变，-w 这个参数就非常有用。
git commit --amend
修补前一次提交。相当于撤销前一次提交，做更改后重新提交。这也是一条非常实用的命令。当你发现前一次提交有一些小问题的时候（比如说漏提交了新创建的文件，或者有一些小的拼写错误），可以用这条命令修正前一次提交。它对 merge 提交友好，而且可以用于修正前一次提交的 message 信息。需要注意的是：如果你已经推送了前一次提交，amend 之后需要强推，这一点需要注意。
git log --graph --oneline --no-merge
显示当前仓库的提交历史。git log 大家都用过，但真正研究过 git log 后面参数的人可能就不多。git log 后面可以接很多实用的参数，示例中的让提交历史以单行模式显示、显示提交历史树并删除 merge 提交。
git log -p --follow --stat -- <PATH>
显示某个文件的提交历史。在 git 中，-- 后接文件路径就代表对单个文件的操作。-p 可以显示具体修改的行，--follow 可以跟踪文件的移动和重命名，--stat 用于显示添加、删除行的数量。
git config --global alias.xx "<COMMAND>"
给某 git 命令创建别名。对于一些比较长的命令，可以创建别名。以后只需要 git xx 即可执行 COMMAND 这条命令
-
git pull --rebase,--rebase可以简写为-r
使用 git rebase 代替 git merge 执行 pull 操作。git pull --rebase 可以构造出非常整齐的提交历史树，强迫症的福利。git 的官方文档一再提醒这是个危险操作，因为它会修改你的代码提交历史。git rebase 的本质是撤销指定的提交，然后以指定的方式重新提交他们。git pull -r 就相当于首先撤销没有推送到远端的 commit，将远程代码覆盖到本地之后，重新提交所有之前撤销的 commit。与 git merge 不同，当有冲突产生时，git rebase 不会为你的 merge 操作生成一个新的提交。所以一旦 git pull --rebase 执行完毕就无法撤销。
git config --global pull.rebase true
默认使用 git rebase 代替 git merge 执行 pull 操作。git 提供了一系列配置 git pull --rebase 操作：branch.<BRANCH NAME>.rebase、branch.autosetuprebase。这条是最简单的全局配置项。尽管配置了默认使用 rebase，你可以使用 --merge 开关强制使用 git merge 执行 git pull。
git rebase -i
交互式变基操作。git 中最强大的修改提交历史的操作，当然也是最危险的操作。它可以让你修改 commit 说明、让几个 commit 合并、交换 commit、删除 commit，甚至在提交某 commit 前执行一段 shell 命令。非常有用、非常强大、同时也是极其危险的操作。强烈建议在执行 git rebase -i 之前先使用 git branch 备份当前分支。
git push <remote> [<commit>]:<branch>
推送指定的 commit 到远程。有时候你某个工作做到一半，然后来了一个bug要修。当然最好的做法是基于最新的远端分支新开一个分支，基于这个分支开发。但是如果你忘了新开分支，直接把代码提交到了当前分支怎么办？在你需要 push 的分支之前又有别的不需要的 commit。这时就可以先用 git rebase 交换 commit 的顺序，然后推送单个提交。如果你写了冒号但是不写 commit 号，就会变成删除某个远端分支。这是完全不同的而且可能有危险操作，需要注意。
git blame <PATH> [-L <M,N>]
逐行检查某文件的提交人、提交时间和 commit 号。blame 的中文意思是追责，大家顾名思义，撕逼甩锅时用。 -L 可以指定要检查的行号。
git stash [push] [-u]
贮存当前工作区的更改。经常有这样的事情发生，当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是你还不想提交这些代码，这是就可以用 git stash 命令将未提交的更改临时保存到一个贮存项中。-u 表示将未加入版本管理的文件也保存（比如新建的一些文件）
-
git stash apply <INDEX>、git stash pop <INDEX>
将最后一次保存的（或指定的某个）贮存项应用至当前工作区。与前面的 git stash [push] 配套使用。 apply 与 pop 的区别是：pop 会在应用更改的同时把所应用的贮存项删除，而 apply 不会。
git cherry-pick -x <COMMIT>..
摘取 某些提交。即把另一个本地分支的 commit 应用到当前分支。如果我们同时维护多个分支，这个操作就很有用。比如说你在主干 master 分支上修复了一个 bug，然后你想把这个修复应用到一个旧版本的分支上，但是你又不想把其他 master 分支的新功能拉进来，这时就可以用 cherry-pick。-x：在提交记录中添加一行 (cherry picked from commit <commit>)，让两个提交关联起来。
git revert <COMMIT>
回滚某个提交。即提交某个 COMMIT 的反提交。最快修复某个 bug 的方式就是把引入 bug 的代码干掉。注意干掉代码不代表就要用 git rebase -i 把提交本身也干掉。
git grep <PATTERN>
在当前加入版本管理的文件中全文检索某字符串。类似于 grep 操作，但是会忽略不需要的（加入 .gitignore 的）文件，非常实用的命令。
git bisect
实用二分查找的方式定位引入问题的提交。快速定位 bug 的方式。在找不到 bug 出现的原因时，不妨用 git bisect 将 bug 先锁定到某个 commit 上。
git clean -fd
删除未追踪的文件。-d 表示连目录也一起删除。-x 表示删除被忽略掉的文件，可以用此命令删除编译生成的文件。可以用 -n 查看有哪些文件将被删除。
git reflog
显示 git 的操作记录。当你使用 git reset --hard 误删某个 commit 时可以用此法抢救回来。
brew install tig
美化 git 输出，重度终端用户的福利。这个其实是工具安利了，它用图形化的方式（ncurses）美化 git 输出，谁用谁知道 :)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。