Git

使用 git add 命令可以把修改文件添加到暂存区域（Staging Area），如表 2 所示。

完成修改，并已暂存后，可以使用 git commit 命令提交修改。

git pull 命令的作用是取回远程仓库中某个分支的更新，再与本地的指定分支合并。它的使用格式为：

$ git pull <远程仓库名> <远程分支名:本地分支名>

其中：“远程仓库名”可以是一个 URL，也可以是远程仓库的名字（远程仓库名字往往为 origin，用命令 git remote -v 可以查看远程仓库名字及其对应的 URL）。

pull 命令实例：

$ git pull origin next:master   # 取回远程仓库origin中分支next上的更新，并与本地master分支合并
$ git pull origin next          # 省略了本地分支名，意味着与本地的当前分支合并
                                #（注：如果本地当前分支为master，则作用和前一条命令相同）

git push 命令的作用是将本地分支的更新，推送到远程仓库相应分支上去。它的使用格式为：

$ git push <远程仓库名> <本地分支名:远程分支名>

其中：“远程仓库名”可以是一个 URL，也可以是远程仓库的名字（远程仓库名字往往为 origin，用命令 git remote -v 可以查看远程仓库名字及其对应的 URL）。

当省略“远程分支名”时，这时表示将本地分支推送与之存在“追踪关系”的远程分支（通常两者同名），如果远程分支不存在，则会新建它。

$ git push origin master        # 将本地master分支推送到origin主机的master分支。如果origin主机上没有master分支，则会新建它

如果当前本地分支与远程分支存在“追踪关系”，则本地分支名（即当前分支名）和远程分支名都可以省略。如：

$ git push origin       # 将本地当前分支推送到远程仓库origin中与之存在“追踪关系”的远程分支上去

如果当前分支只有一个追踪分支（注：当前分支可以“追踪”不同的远程仓库上的分支，如当前分支可追踪远程 origin1 和 origin2 上的分支），那么远程仓库名也可以省略。如：

$ git push              # 将本地当前分支推送到与之存在“追踪关系”的唯一（或者默认）远程分支上去

输入 git tag 可以按字母顺序列出标签。如：

$ git tag                    # 列出所有标签
v0.1
v1.3

你可以通过 -l 选项指定特定“模式”来查找标签。例如，Git 自身的源代码仓库包含标签的数量超过 500 个。如果只对 v1.8.5 开头的标签感兴趣，可以运行：

$ git tag -l 'v1.8.5*'       # 列出以 v1.8.5 开头的标签
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5

Git 有两种类型的标签：“轻量标签（lightweight）”与“附注标签（annotated）”。

“轻量标签”很像一个不会改变的分支——它只是一个特定 commit 的引用。

“附注标签”是存储在 Git 数据库中的一个完整对象，它会包含打标签者的名字、电子邮件等信息，还包含一个标签信息（通过 -m 选项可以指定标签信息，不提供该选项时会打开编辑器提示你输入），还可以对附注标签进行签名。通常建议创建附注标签，这样你可以拥有以上所有信息；但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的。

默认情况下， git push 命令并不会传送标签到远程仓库服务器上。

在创建完标签后你必须“显式地”推送标签到服务器上，相应命令为： git push origin [tagname] ，如：

$ git push origin v1.5                # 推送标签 v1.5 到服务器
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new tag]         v1.5 -> v1.5

如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。这将会把所有不在远程仓库服务器上的标签全部传送到那里。

$ git push origin --tags              # 指定 --tags，可推送所有标签到服务器
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

在 Git 中你并不能真的签出一个标签，因为它们并不能像分支一样来回移动。如果你想要工作目录与仓库中特定的标签版本完全一样，可以使用 git checkout -b [branchname] tags/[tagname] 在特定的标签上创建一个新分支：

$ git checkout -b version2 tags/v2.0.0  # 基于标签 v2.0.0，创建分支 version2，并切换到改分支
$ git checkout -b version2 v2.0.0       # 同上。不过如果已经存在名为 v2.0.0 的分支，则会失败

当然，如果在这之后又进行了一次提交，version2 分支会因为改动向前移动了，那么 version2 分支就会和 v2.0.0 标签稍微有些不同，这时就应该当心了。

通过 -d 选项可以删除标签，如：

$ git tag -d v1.4                   # 删除名为 v1.4 的标签
Deleted tag 'v1.4' (was ca82a6df)

下面命令可以删除远程标签：

$ git push origin :refs/tags/<tag_name>   # 删除远程标签 tag_name
$ git push origin :<tag_name>             # 同上，不过当 tag_name 同时是分支名时会失败

使用 git branch -r 可以查看已经下载到本地的远程分支。

使用 git ls-remote --heads <remote-name> 可以查看所有远程分支（包含还没下载到本地的远程分支）。如：

$ git ls-remote --heads origin

使用 git ls-remote --heads [url] 可以列出工程的所有远程分支（指定 heads 的作用是仅显示分支名，不显示 tag 名）， 它不需要 clone 工程。 如：

$ git ls-remote --heads https://github.com/opencv/opencv.git
43f1b72e92deab7e79a92c5d40ca2c561c50c0a0	refs/heads/2.4
a50a355e637d7a3b1519803cde1fdcfa7b9de3cb	refs/heads/master

上面的输出表明 url 所指定的工程中存在两个远程分支，其名字为“2.4”和“master”。

创建远程分支的步骤：

$ git checkout -b <your-new-branch-name>        # 基于当前分支新建本地分支，并切换到该分支
$ git push <远程仓库名> <your-new-branch-name>  # 推送分支到远程仓库，远程无同名分支时会创建它

说明，命令中 git checkout -b <your-new-branch-name> 是下面两个命令的简写：

$ git branch <your-new-branch-name>             # 基于当前分支新建本地分支
$ git checkout <your-new-branch-name>           # 切换到该分支

注：要删除远程分支，可参考节 2.2.2.2 。

在 Git 中重命名远程分支，其实重命名本地分支、删除旧远程分支，再重新提交一个远程分支。

假设远程分支名为“old-name”，现在想把它改名为“new-name”。其操作步骤为：

$ git branch -m old-name new-name   # 重命名分支
$ git push origin :old-name         # 删除旧的远程分支
$ git push origin -u new-name       # 把新本地分支推送到服务器（创建新的远程分支）

参考：Rename a local and remote branch in git

使用 git branch -a 可以查看所有分支的列表。如：

$ git branch -a
 * develop
   master
   remotes/origin/HEAD -> origin/master
   remotes/origin/develop
   remotes/origin/master
   remotes/origin/bugfix1

如果其它人删除了某个远程分支（如 bugfix1），执行 git branch -a 命令时上面列表并不会自动更新。使用命令 git remote update origin --prune 可以更新远程分支列表，删除不存在的远程分支。如：

$ git remote update origin --prune
Fetching origin
From https://github.com/xxx/proj1
 - [deleted]         (none)     -> origin/bugfix1
$ git branch -a
 * develop
   master
   remotes/origin/HEAD -> origin/master
   remotes/origin/develop
   remotes/origin/master

参考：
https://stackoverflow.com/questions/36358265/when-does-git-refresh-the-list-of-remote-branches

假设当前代码提交历史为图 6 所示。

通过下面命令，可以把分支 hotfix 合并到分支 master 上：

$ git checkout master                # 第一步，切换到分支master
$ git merge hotfix                   # 第二步，使用git merge合并分支hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

完成合并后，代码提交历史变为如图 7 所示。

现在考虑一个稍微复杂些的分支合并的例子，假设当前代码提交历史为图 8 所示。

通过下面命令，可以把分支 iss53 合并到分支 master 上：

$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

这和你之前合并 hotfix 分支的时候看起来有一点不一样。在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并（three-way merge）。如图 9 所示。

和实例一中将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。如图 10 所示。

如何 Merge 其它分支的 commit 到当前分支呢？使用 git cherry-pick <commit-id> 命令即可，如：

$ git cherry-pick d42c389f

参考：https://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git

当 cherry-pick 的 commit 不是普通 commit，而是一个 merge commit 时，你需要指定 -m 选项（或者 --mainline ）来避免歧义。

比如你的 commit history 是这样的：

- A - B - E - F -   master
   \     /
    C - D           fix

显然，E 是一个 merge commit。如果你现在要在其他地方 git cherry-pick E ，那么就会有歧义，因为 E 既可以是来自 master 分支 B - E 的改动 (diff)，也可以是来自 fix 分支 D - E 的改动 (diff)。

按照这个例子，fix 是被 merge 到 master 的。因此， 命令 git cherry-pick E -m 1 意思就是使用 B - E 的改动，命令 git cherry-pick E -m 2 意思就是使用 D - E 的改动。 记住一点就好，1 是 “主干”，确切点儿说是被 merge 了代码的 branch，2 是 merge 来源。

参考：https://segmentfault.com/q/1010000010185984

使用 git merge-base 可以查看两个分支的第一个公共祖先。如：

$ git merge-base branch1 branch2
050dc022f3a65bdc78d97e2b1ac9b595a924c3f2

参考：https://stackoverflow.com/questions/1549146/how-to-find-the-most-recent-common-ancestor-of-two-git-branches

使用 git reset 可以让当前分支回滚到任何一个历史版本，直接移除那以后的所有提交。但这更改了 Git 的历史，Git 服务通常会禁止这样做。下面介绍一种安全回滚到历史版本的方式。

第一步，通过 git log 找到你想要回到的版本的 commit hash。假设想回到 commit hash 为 4a50c9f 的版本（即放弃最近的两个版本）。

$ git log --graph --oneline
 * d4ccf59 (HEAD -> master) version 4 (harttle screwed it up, again)
 * 5b7d48e version 3 (harttle screwed it up)
 * 4a50c9f version 2                                        <---- 想回到这个版本
 * 491c6e0 version 1

第二步，基于 4a50c9f 创建一个本地分支（假设名为 v2），并切换到 v2。如：

$ git checkout -b v2 4a50c9f

这时，commit log 如下：

$ git log --graph --oneline
 * d4ccf59 (master) version 4 (harttle screwed it up, again)
 * 5b7d48e version 3 (harttle screwed it up)
 * 4a50c9f (HEAD -> v2) version 2
 * 491c6e0 version 1

现在 HEAD 已经指向 v2 分支。

第三步，通过 -s ours 指定 ours 合并策略来合并 master 分支到 v2。如：

$ git merge -s ours master

-s ours master 合并的结果是 产生了一个基于 master 的 commit，但 HEAD 中的代码和 v2 完全相同。

这时，commit log 如下：

$ git log --graph --oneline
 *   94fa8a7 (HEAD -> v2) Merge branch 'master' into v2
 |\
 | * d4ccf59 (master) version 4 (harttle screwed it up, again)
 | * 5b7d48e version 3 (harttle screwed it up)
 |/
 * 4a50c9f version 2
 * 491c6e0 version 1

第四步，push 分支 v2 到远程 master 分支。如：

$ git push origin v2:master

参考：安全地回滚远程分支

merge -s ours 和 merge -X ours （它是 merge -s recursive -X ours 的简写）是不同的。关于 merge -s ours 的作用可参考上一节内容。

Git 合并策略有很多种（可参考MERGE STRATEGIES），如 recursive/ours/subtree 等等，通过 -s 可以指定合并策略。通过 -X 可以指定合并策略的更具体选项，如合并策略 recursive 支持很多具体选项如 ours/theirs，它们的含义如下：

$ git merge branch1                         # 是 git merge -s recursive branch1 的简写
$ git merge -s recursive branch1            # 使用recursive策略合并branch1到当前分支，有冲突时，需要用户手动resolve
$ git merge -s recursive -X ours branch1    # 使用recursive策略合并branch1到当前分支，遇到冲突时自动采用当前分支的中版本
$ git merge -s recursive -X theirs branch1  # 使用recursive策略合并branch1到当前分支，遇到冲突时自动采用分支branch1中的版本

假设你从 master 分支拉了一个新分支，取名为 speedup，你在 speedup 分支上进行开发，且提交了 3 次，如图 11 所示。

现在你想把 speedup 分支 merge 回 master。假设从你拉分支 speedup 出来后的这段时间内，master 分支上一直没有新的 commit，则你可以选择 Fast-Forward merge（默认行为）和 No Fast-Forward merge（可通过 -no-ff 来指定）。它们的区别如图 12 所示，采用 No Fast-Forward merge 时多了一个提交记录（多了虚线圆圈所表示的 commit）。

说明：如果从你拉分支 speedup 出来后的这段时间内，master 分支上有新的 commit，则把 speedup 分支 merge 回 master 时是无法进行 Fast-Forward merge 的（不过，你也不用特意指定 -no-ff ，git 发现无法进行 Fast-Forward merge 时会自动转为 No Fast-Forward 方式进行 merge）。

参考：https://ariya.io/2013/09/fast-forward-git-merge

git merge 和 git rebase 从最终效果来看没有任何区别，都是将不同分支的代码融合在一起，但是生成的代码树就稍微有些不同，如图13所示， 使用 rebase 后提交历史是一条直线没有分叉。

参考：http://www.cnblogs.com/iammatthew/archive/2011/12/06/2277383.html

可以把衍合当成一种在推送之前清理提交历史的手段，仅仅衍合那些永远不会公开的 commit。换句话说，当本地有 commit，而需要和别人的 commit 合并时，建议使用 rebase 来保证修改历史的轨迹的简洁。

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果衍合那些已经公开的 commit，而与此同时其他人已经用这些 commit 进行了后续的开发工作，那你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容的时候事情就会变得一团糟。

在使用 git pull 更新代码时，可能会碰到冲突的情况，提示信息：

$ git pull
error: Your local changes to 'file1' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.

解决办法：
第一步，先把你本地的修改放入到内部栈中，即：

$ git stash

第二步，运行 git pull ，不再会有冲突的提示了。

第三步，恢复本地的修改到工作区中（会提示冲突），即：

$ git stash pop
Auto-merging file1
CONFLICT (content): Merge conflict in file1

第四步，打开冲突文件，手动解决冲突。如：

<<<<<<< Updated upstream
  This foo
=======
  This bar
>>>>>>> Stashed changes

其中，“<<<<<<< Updated upstream”和“=======”之间的内容是 pull 下来的内容，而“=======”和“>>>>>>> Stashed changes”之间的内容是本地修改的内容。

使用 git log --graph 可以显示 commit tree。如：

$ git log --graph --oneline
 * 7add224 change2
 *   fd44ce9 Merge branch 'master' into rollback
 |\
 | * 21162bc update1
 |/
 * 1733aa6 first commit

只显示某个用户的提交日志：

$ git log --author=<name or email>

有时使用 git status 命令并不会显示还未 push 到远程服务器的 commit。

下面这些命令都可以显示还未 push 到远程服务器的 commit：

$ git log origin/master..HEAD           # 查看分支origin/master上还未push到远程服务器的commit
$ git cherry -v origin/master           # 查看分支origin/master上还未push到远程服务器的commit
$ git log --branches --not --remotes    # 查看所有分支上还未push到远程服务器的commit

参考：https://stackoverflow.com/questions/2016901/viewing-unpushed-git-commits

例如，如果我们想找到“ZLIB_BUF_MAX”常量是什么时候引入的，我们可以使用 -S<string> 选项来显示新增和删除该字符串的提交。

$ git log -SZLIB_BUF_MAX --oneline
e01503b zlib: allow feeding more than 4GB in one go
ef49a7a zlib: zlib can only process 4GB at a time

如果我们查看这些提交的详细信息，我们可以看到在 ef49a7a 这个提交引入了常量，并且在 e01503b 这个提交中被修改了。

如果你希望得到更精确的结果，你可以使用 -G<regex> 选项来使用正则表达式搜索。

要查看文件“file.txt”中第 10 行到 15 行的所有修改历史，可以执行下面命令：

$ git log -L 10,15:file.txt

参考：https://stackoverflow.com/questions/8435343/retrieve-the-commit-log-for-a-specific-line-in-a-file

显示所有提交者及其 email 地址：

$ git log --all --format='%aN <%cE>' | sort -u

使用 git shortlog -s 可以显示每个提交者的 commit 数量，再加上选项 -n 可以按 commit 数量进行排序。如在 redis 源码根目录执行 git shortlog -sn 可得到下面输出：

$ git shortlog -sn
  5339  antirez
   512  Salvatore Sanfilippo
   510  Pieter Noordhuis
   151  Matt Stancliff
   116  zhaozhao.zz
    87  artix
    54  Oran Agra
    48  Itamar Haber
    35  Yossi Gottlieb
    34  Dvir Volk
......

直接使用 git show 无法查看通过 merge 创建的 commit 的具体修改内容。如：

$ git show c05f017         # 我们期望显示commit的具体修改内容，但并没有显示
commit c0f50178901e09a1237f7b9d9173ec5d1c4936c
Merge: ed234b ded051
Author: abc
Date:   Mon Nov 21 15:56:33 2016 -0800

    Merge branch 'abc'

有两种方法可以查看通过 merge 创建的 commit 的修改内容：

$ git show -m c05f017    # 方法一，使用 -m 选项
$ git show ded051        # 方法二，直接查看merge commit id（ded051来自于Merge: ed234b ded051）

参考：https://stackoverflow.com/questions/40986518/git-show-of-a-merge-commit

如果你在 git blame 后面加上一个 -C ，Git 会分析你正在标注的文件，并且尝试找出文件中从别的地方复制过来的代码片段的原始出处。

比如，你将 GITServerHandler.m 这个文件拆分为数个文件，其中一个文件是 GITPackUpload.m。 对 GITPackUpload.m 执行带 -C 参数的 blame 命令，你就可以看到代码块的原始出处：

$ git blame -C -L 141,153 GITPackUpload.m
f344f58d GITServerHandler.m (Scott 2009-01-04 141)
f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 145)
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 146)         NSString *parentSha;
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 147)         GITCommit *commit = [g
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 148)
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 149)         //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 150)
56ef2caf GITServerHandler.m (Scott 2009-01-05 151)         if(commit) {
56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
56ef2caf GITServerHandler.m (Scott 2009-01-05 153)

下面命令可以放弃所有的本地 commit（没有 push 到远程仓库的 commit），让本地代码和远程的某个分支代码一样：

$ git reset --hard origin/<branch_name>  # 替换<branch_name>为远程分支名
$ git reset --hard origin/master         # 让本地代码和origin/master代码一样，丢掉所有本地修改

参考：https://stackoverflow.com/questions/5097456/throw-away-local-commits-in-git

删除最近的一次 commit，但保留你的修改：

$ git reset --soft HEAD~1

删除最近的一次 commit，而且删除你的修改：

$ git reset --hard HEAD~1

如果你需要放弃多个本地的 commit，连续运行多次即可。

参考：https://stackoverflow.com/questions/3197413/how-do-i-delete-unpushed-git-commits

使用 checkout 可放弃某个文件的本地修改。如：

$ git checkout path/to/file     # 放弃文件path/to/file的修改
$ git checkout .                # 放弃当前目录的修改

不过，如果本地文件有一些 merger 冲突未解决，上面命令可以提示错误“error: path 'path/to/file' is unmerged”。这时，可以用下面命令来放弃文件的本地修改：

#### 放弃文件 path/to/file 的本地修改
$ git reset path/to/file
$ git checkout path/to/file

参考：http://stackoverflow.com/questions/1146973/how-do-i-revert-all-local-changes-in-git-managed-project-to-previous-state

下面步骤可撤销最近一次（或多次）提交到服务器的 commit：

$ git pull                   # 确保你的代码和服务器一致
$ git reset --hard HEAD~     # 在本地删除最近的一次 commit。要撤销多个 commit，请运行多次。使用 --soft 可保留修改
$ git push origin +master    # 推送到服务器，其中 + 号表示强行推送

参考：https://ncona.com/2011/07/how-to-delete-a-commit-in-git-local-and-remote/

下面是在 commit 前自动格式化 golang 源代码的 hook 实例（下面脚本中， git diff --cached --name-only 的作用是寻找本次 commit 所修改的文件）：

#!/bin/sh
# To use, store as .git/hooks/pre-commit inside your repository and make sure
# it has execute permissions.
#
# This script does not handle file names that contain spaces.

gofiles=$(git diff --cached --name-only --diff-filter=ACM | grep '\.go$')
[ -z "$gofiles" ] && exit 0

unformatted=$(gofmt -l $gofiles)
[ -z "$unformatted" ] && exit 0

# Some files are not gofmt'd. Print message and fail.

echo >&2 "Go files must be formatted with gofmt before commit. Please run:"
for fn in $unformatted; do
    echo >&2 "  gofmt -w $PWD/$fn"
done

exit 1

# copy from https://golang.org/misc/git/pre-commit

把上面脚本命名为 pre-commit 后，复制到.git/hooks 目录中，并设置可执行权限即可生效。

不过，由于.git 目录中的文件不能 push 到服务器，我们一般把它放到项目根目录的其它目录中（比如 githooks），再把 githooks 中的文件软链接到.git/hooks 中：

$ find githooks -type f -exec ln -sf ../../{} .git/hooks/ \;

设置 SourceGear DiffMerge 作为解决 merge 冲突的图形工具：

$ git config --global merge.tool diffmerge
$ git config --global mergetool.diffmerge.cmd 'diffmerge --merge --result="$MERGED" "$LOCAL" "$(if test -f "$BASE"; then echo "$BASE"; else echo "$LOCAL"; fi)" "$REMOTE"'
$ git config --global mergetool.diffmerge.trustExitCode true
$ git config --global mergetool.keepBackup false

执行完 merge 命令，如果提示有冲突，则可以使用下面命令启动图形工具 SourceGear DiffMerge 解决冲突：

$ git mergetool             # 启动图形工具diffmerge解决冲突

设置 SourceGear DiffMerge 作为查看 diff 的图形工具：

$ git config --global diff.tool diffmerge
$ git config --global difftool.diffmerge.cmd 'diffmerge "$LOCAL" "$REMOTE"'

下面是使用 git difftool 的一些例子：

#### diff the local file.m against the checked-in version
$ git difftool file.m

#### diff the local file.m against the version in some-feature-branch
$ git difftool some-feature-branch file.m

#### diff the file.m from the Build-54 tag to the Build-55 tag
$ git difftool Build-54..Build-55 file.m

#### diff all files from the Build-54 tag to the Build-55 tag
$ git difftool Build-54..Build-55

使用 --single-branch -b <branch_name> 可以只克隆指定的某个分支。如：

$ git clone --single-branch -b <branch_name> <remote_repo_url>

如果一个项目非常大，直接克隆会下载所在的历史版本记录，导致克隆时间比较长。若仅需要最新的版本，可以使用 git clone --depth=1 <remote_repo_url> ，可加快克隆速度，如：

$ git clone --depth=1 https://github.com/rust-lang/rust.git
Cloning into 'rust'...
remote: Counting objects: 7247, done.
remote: Compressing objects: 100% (6469/6469), done.
remote: Total 7247 (delta 3958), reused 1643 (delta 736), pack-reused 0
Receiving objects: 100% (7247/7247), 8.29 MiB | 100.00 KiB/s, done.
Resolving deltas: 100% (3958/3958), done.
Checking connectivity... done.

参考：
git help clone
https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_do_a_quick_clone_without_history_revisions.3F

如果仅想克隆某个 tag 下的代码，在执行 clone 命令时指定 --branch=<tag_name> 即可，当然同时指定 --depth=1 可以进一步加快克隆速度，如：

$ git clone https://github.com/torvalds/linux.git --depth=1 --branch=v5.0

commit 后（还未 push），发现填写的 message 不正确，如何修改呢？可用下面方法：

$ git commit --amend

参考：http://stackoverflow.com/questions/179123/edit-an-incorrect-commit-message-in-git

如何修改历史 commit 中的 author 信息，比如 author 的名称或者其邮件地址？答案是使用 git filter-branch 命令。

下面实例将修改历史 commit 的 author 信息：把 commit 中所有的“your-old-email@example.com”邮件地址修改为“your-correct-email@example.com”，同时名称修改为“Your Correct Name”。

第一步，以“裸版本库”的方式克隆工程：

$ git clone --bare https://github.com/user/repo.git
$ cd repo.git

第二步：执行下面 git filter-branch 命令把旧邮件地址修改为新邮件地址：

$ git filter-branch --env-filter '

OLD_EMAIL="your-old-email@example.com"          # 请修改它
CORRECT_NAME="Your Correct Name"                # 请修改它
CORRECT_EMAIL="your-correct-email@example.com"  # 请修改它

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

第三步：执行下面命令，以 push 到服务器：

$ git push --force --tags origin 'refs/heads/*'

第四步：删除之前克隆的工程。

$ cd ..
$ rm -rf repo.git

注：这样的修改不会改变 commit 的提交时间。

参考：https://help.github.com/en/articles/changing-author-info

不小心提交了二进制文件，简单地删除，其实它还是位于历史记录中。下面介绍如何从历史记录中彻底删除二进制文件。

第一步，使用 --bare 选项克隆仓库：

$ git clone --bare  https://github.com/your_name/your_project.git

第二步，找到所有二进制文件：

$ cd your_project.git
$ git log --all --numstat \
    | grep '^-' \
    | cut -f3 \
    | sed -r 's|(.*)\{(.*) => (.*)\}(.*)|\1\2\4\n\1\3\4|g' \
    | sort -u

第三步，删除它：

$ git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch path/to/your/binary/file" \
  --prune-empty --tag-name-filter cat -- --all

修改上面命令中的“path/to/your/binary/file”为第二步中找到的二进制文件的完整路径，如果有多个，请替换后执行多次。

最后一步，提交修改：

$ git push --force --tags origin 'refs/heads/*'

下面步骤将清除 master 分支所有的 commit 信息，并把当前代码重新 push 到 master 分支：

git checkout --orphan latest_branch   # Checkout to branch latest_branch
git add -A                            # Add all the files
git commit -am "commit message"       # Commit the changes
git branch -D master                  # Delete the branch master
git branch -m master                  # Rename the current branch to master
git push -f origin master             # Finally, force update your repository

参考：https://stackoverflow.com/questions/13716658/how-to-delete-all-commit-history-in-github

如果你想要所有 git 仓库都忽略某些文件或目录，你可以把它们写到文件“~/.gitignore_global”中，然后执行下面命令：

$ git config --global core.excludesfile ~/.gitignore_global

参考：https://help.github.com/en/github/using-git/ignoring-files#create-a-global-gitignore