zh_cn/grandmaster.txt

   1 == Git大师技 ==
   2
   3 到现在，你应该有能力查阅 *git help* 页，并理解几乎所有东西。然而，查明解决特
   4 定问题需要的确切命令可能是乏味的。或许我可以省你点功夫：以下是我过去曾经用到
   5 的一些技巧。
   6
   7 === 源码发布 ===
   8
   9 就我的项目而言，Git完全跟踪了我想打包并发布给用户的文件。如需创建一个源码包，我
  10 会运行：
  11
  12  $ git archive --format=tar --prefix=proj-1.2.3/ HEAD
  13
  14 === 提交变更  ===
  15
  16 对特定项目而言，告诉Git你增加，删除和重命名了一些文件很麻烦。而键入如下命令会容易
  17 的多：
  18
  19  $ git add .
  20  $ git add -u
  21
  22 Git将查找当前目录的文件并计算出所有更改过的内容。除了第二个add命令，如果你也打
  23 算同时提交，则可以运行`git commit -a`。关于如何指定应被忽略的文件，参见 *git
  24 help ignore* 。
  25
  26 你也可以用一行命令完成以上任务：
  27
  28  $ git ls-files -d -m -o -z | xargs -0 git update-index --add --remove
  29
  30 这里 *-z* 和 *-0* 选项可以消除包含特殊字符的文件名引起的不良副作用。注意这个
  31 命令也会添加本应被忽略的文件，这时你可能需要加上 `-x` 或 `-X` 选项。
  32
  33 === 我的提交太大了！ ===
  34
  35 是不是忽略提交太久了？一直痴迷于写代码，直到现在才想起有源码控制工具这回事？或者
  36 提交一系列不相关的变更，因为你更喜欢这么做？
  37
  38 别担心，运行：
  39
  40  $ git add -p
  41
  42 对你做过的每次修改，Git都将展示变动过的代码，并询问该变动是否应是下一次提交的一
  43 部分。回答“y”或者“n”。当然也有其他选项，比如延迟决定；键入“？”来学习更多。
  44
  45 一旦你满意，键入
  46
  47  $ git commit
  48
  49 来精确地提交你所选择的变更（阶段变更）。注意请勿加上 *-a* 选项，否则Git将提交
  50 所有修改。
  51
  52 如果你修改了许多地方的许多文件怎么办？一个一个地查看这些变更会令人沮丧，心态麻木。
  53 这种情况下，使用 *git add -i* ， 它的界面不是很直观，但更灵活。敲几个键，你可
  54 以一次决定阶段或非阶段性提交几个文件，或查看并只选择特定文件的变更。作为另一
  55 种选择，你还可以运行 *git commit --interactive* ，这个命令会在你操作完后自动
  56 进行提交。
  57
  58 === 索引：Git的中转区域 ===
  59
  60 当目前为止，我们一直在忽略Git著名的“索引”概念，但现在我们必须面对它，以解释上
  61 面发生的事情。索引是一个临时中转区。Git很少在你的项目和它的历史之间直接倒腾数据。
  62 通常，Git先写数据到索引，然后拷贝索引中的数据到最终目的地。
  63
  64 例如， *commit -a* 实际上是一个两步过程。第一步把每个追踪文件当前状态的快照放
  65 到索引中。第二步永久记录索引中的快照。 没有 *-a* 的提交只执行第二步，并且只在
  66 运行不知何故改变索引的命令才有意义，比如 *git add* 。
  67
  68 通常我们可以忽略索引并假装从历史中直接读并直接写。在这个情况下，我们希望更好
  69 地控制，因此我们操作索引。我们放我们变更的一些的快照到索引中，而不是所有的，
  70 然后永久地记录这个被小心操纵的快照。
  71
  72 === 别丢了你的HEAD ===
  73
  74 HEAD好似一个游标，通常指向最新提交，随最新提交向前移动。一些Git命令可让你来移动
  75 它。 例如：
  76
  77  $ git reset HEAD~3
  78
  79 这将立即将HEAD向回移动三个提交。这样所有Git命令都表现得好似你没有做那最后三个提交，
  80 然而你的文件保持在现在的状态。具体应用参见帮助页。
  81
  82 但如何回到将来呢？过去的提交对将来一无所知。
  83
  84 如果你有原先Head的SHA1值，那么：
  85
  86  $ git reset 1b6d
  87
  88 但假设你从来没有记下呢？别担心，在这些命令里面，Git会将原先的Head保存为一个叫做
  89 ORIG_HEAD的标记，你可以安全体面的返回那里：
  90
  91  $ git reset ORIG_HEAD
  92
  93 === HEAD捕猎 ===
  94
  95 或许ORIG_HEAD还不够；或许你刚认识到你犯了个历史性的错误，你需要回到一个早已忘记
  96 分支上一个远古的提交。
  97
  98 默认的，Git将会将一个提交保存至少两星期，即使你命令Git摧毁该提交所在的分支。难点
  99 是找到相应的哈希值。你可以查看在.git/objects里所有的哈希值并尝试找到你期望的提
 100 交。但这里有一个更简单的办法。
 101
 102 Git把算出的提交哈希值记录在“.git/logs”。这个子目录引用包括所有分支上所有活
 103 动的历史，同时文件HEAD显示它曾经有过的所有哈希值。后者可用来发现分支上一些不
 104 小心丢掉提交的哈希值。
 105
 106 命令reflog为访问这些日志文件提供了友好的接口，可以试试
 107
 108   $ git reflog
 109
 110 而不是从reflog拷贝粘贴哈希值，试一下：
 111
 112  $ git checkout "@{10 minutes ago}"
 113
 114 或者捡出后五次访问过的提交，通过：
 115
 116  $ git checkout "@{5}"
 117
 118 更多内容参见 *git help rev-parse* 的``Specifying Revisions''部分。
 119
 120 你或许期望去为已删除的提交设置一个更长的保存周期。例如：
 121
 122   $ git config gc.pruneexpire "30 days"
 123
 124 意思是一个被删除的提交会在删除30天并运行 *git gc* 以后，被永久丢弃。
 125
 126 你或许还想关掉 *git gc* 的自动运行：
 127
 128   $ git config gc.auto 0
 129
 130 在这种情况下提交将只在你手工运行 *git gc* 的情况下才永久删除。
 131
 132 === 基于Git构建 ===
 133
 134 依照真正的UNIX风格设计，Git允许其易于用作其他程序的底层组件，比如图形界面，
 135 Web界面，可选择的命令行界面，补丁管理工具，导入和转换工具等等。实际上，一些
 136 Git命令它们自己就是站在巨人肩膀上的脚本。通过一点修补，你可以定制Git适应你的
 137 偏好。
 138
 139 一个简单的技巧是，用Git内建alias命令来缩短你最常使用命令：
 140
 141   $ git config --global alias.co checkout
 142   $ git config --global --get-regexp alias  # 显示当前别名
 143   alias.co checkout
 144   $ git co foo                              # 和“git checkout foo”一样
 145
 146 另一个技巧，在提示符或窗口标题上打印当前分支。调用：
 147
 148   $ git symbolic-ref HEAD
 149
 150 显示当前分支名。在实际应用中，你可能最想去掉“refs/heads/”并忽略错误：
 151
 152   $ git symbolic-ref HEAD 2> /dev/null | cut -b 12-
 153
 154 子目录 +contrib+ 是一个基于Git工具的宝库。它们中的一些命令不时的会被提升为官方
 155 命令。在Debian和Ubuntu，这个目录位于 +/usr/share/doc/git-core/contrib+ 。
 156
 157 一个受欢迎的居民是 +workdir/git-new-workdir+ 。通过聪明的符号链接，这个脚本创
 158 建一个新的工作目录，其历史与原来的仓库共享：
 159
 160   $ git-new-workdir an/existing/repo new/directory
 161
 162 这个新的目录和其中的文件可被视为一个克隆，除了历史是共享的，两者的树会自动保持
 163 同步，而不必合并，推入或拉出。
 164
 165 === 大胆的特技 ===
 166
 167 最近以来，Git努力使用户因意外而销毁数据变得更困难。但如若你知道你在做什么，你可
 168 以突破为通用命令所设的保障措施。
 169
 170 *Checkout*：未提交的变更会导致捡出失败。销毁你的变更，并无论如何都checkout一
 171  个指定的提交，使用强制标记：
 172
 173   $ git checkout -f HEAD^
 174
 175 另外，如果你为捡出指定特别路径，那就没有安全检查了。提供的路径将被不加提示地
 176 覆盖。如你使用这种方式的检出，要小心。
 177
 178 *Reset*: 如有未提交变更重置也会失败。强制其通过，运行：
 179
 180   $ git reset --hard 1b6d
 181
 182 *Branch*: 引起变更丢失的分支删除会失败。强制删除，键入：
 183
 184   $ git branch -D dead_branch  # instead of -d
 185
 186 类似，通过移动试图覆盖分支，如果随之而来有数据丢失，那么覆盖也会失败。强制移动
 187 分支，键入：
 188
 189   $ git branch -M source target  # 而不是 -m
 190
 191 不像checkout和重置，这两个命令将延迟数据销毁。这个变更仍然存储在.git的子目录里，
 192 并且可以通过恢复.git/logs里的相应哈希值获取（参见上面 上面“HEAD猎捕”）。默
 193 认情况下，这些数据会保存至少两星期。
 194
 195 *Clean*: 一些Git命令拒绝执行，因为它们担心会重装未纳入管理的文件。如果你确信
 196  所有未纳入管理的文件都是消耗品，那就无情地删除它们，使用：
 197
 198   $ git clean -f -d
 199
 200 下次，那个讨厌的命令就会工作！
 201
 202 === 阻止坏提交 ===
 203
 204 愚蠢的错误会污染我的代码库。最可怕的是由于忘记 *git add* 而引起的文件丢失。较小
 205 的错误则是行末追加空格而引发合并冲突：尽管危害少，我希望这些永远不要出现在公开
 206 记录里。
 207
 208 不过我购买了傻瓜保险，通过使用一个_钩子_来提醒我这些问题：
 209
 210  $ cd .git/hooks
 211  $ cp pre-commit.sample pre-commit  # 对旧版本Git，先运行chmod +x
 212
 213 现在如果Git检测到无用的空格或未解决的合并冲突，它将放弃合并。
 214
 215 对本文档，我最终添加以下到 *pre-commit* 钩子的前面，来防止缺魂儿的事：
 216
 217  if git ls-files -o | grep '\.txt$'; then
 218    echo FAIL! Untracked .txt files.
 219    exit 1
 220  fi
 221
 222 一部分其他的Git操作也支持钩子；参见 *git help hooks* 。我们早先激活了作为例子的
 223 *post-update* 钩子，当讨论基于HTTP的Git的时候。无论head何时移动，这个钩子都会
 224 运行。例子中的脚本post-update会在Git面对并不知晓的传输协议，诸如HTTP时，更新自己的
 225 资料库，以确保它有能力交换所需的文件。