zh_tw/history.txt

   1 == 關於歷史 ==
   2
   3 Git分散式本性使得歷史可以輕易編輯。但你若篡改過去，需要小心：只重寫你獨自擁有
   4 的那部分。正如民族間會無休止的爭論誰犯下了什麼暴行一樣，如果在另一個人的克隆
   5 裡，歷史版本與你的不同，當你們的樹互操作時，你會遇到一致性方面的問題。
   6
   7 一些開發人員強烈地感覺歷史應該永遠不變，不好的部分也不變所有都不變。另一些覺
   8 得代碼樹在向外發佈之前，應該整得漂漂亮亮的。Git同時支持兩者的觀點。像克隆，分
   9 支和合併一樣，重寫歷史只是Git給你的另一強大功能，至于如何明智地使用它，那是你
  10 的事了。
  11
  12 === 我認錯 ===
  13
  14 剛提交，但你期望你輸入的是一條不同的信息？那麼鍵入：
  15
  16  $ git commit --amend
  17
  18 來改變上一條信息。意識到你還忘記了加一個檔案？運行git add來加，然後運行上面的
  19 命令。
  20
  21 希望在上次提交裡包括多一點的改動？那麼就做這些改動並運行：
  22
  23  $ git commit --amend -a
  24
  25 === 更複雜情況 ===
  26
  27 假設前面的問題還要糟糕十倍。在漫長的時間裡我們提交了一堆。但你不太喜歡他們的
  28 組織方式，而且一些提交信息需要重寫。那麼鍵入：
  29
  30  $ git rebase -i HEAD~10
  31
  32 並且後10個提交會出現在你喜愛的$EDITOR。一個例子：
  33
  34     pick 5c6eb73 Added repo.or.cz link
  35     pick a311a64 Reordered analogies in "Work How You Want"
  36     pick 100834f Added push target to Makefile
  37
  38 之後：
  39
  40 - 通過刪除行來移去提交。
  41 - 通過為行重新排序行來重新排序提交。
  42 - 替換 `pick` 使用：
  43    * `edit` 標記一個提交需要修訂。
  44    * `reword` 改變日誌信息。
  45    * `squash` 將一個提交與其和前一個合併。
  46    * `fixup` 將一個提交與其和前一個合併，並丟棄日誌信息。
  47
  48 保存退出。如果你把一個提交標記為可編輯，那麼運行
  49
  50  $ git commit --amend
  51
  52 否則，運行：
  53
  54  $ git rebase --continue
  55
  56 這樣儘早提交，經常提交：你之後還可以用rebase來規整。
  57
  58 === 本地變更之後 ===
  59
  60 你正在一個活躍的項目上工作。隨着時間推移，你做了幾個本地提交，然後你使用合併
  61 與官方版本同步。在你準備好提交到中心分支之前，這個循環會重複幾次。
  62
  63 但現在你本地Git克隆摻雜了你的改動和官方改動。你更期望在變更列表裡，你所有的變
  64 更能夠連續。
  65
  66 這就是上面提到的 *git rebase* 所做的工作。在很多情況下你可以使用 *--onto* 標
  67 記以避免交互。
  68
  69 另外參見 *git help rebase* 以獲取這個讓人驚奇的命令更詳細的例子。你可以拆分提
  70 交。你甚至可以重新組織一棵樹的分支。
  71
  72 === 重寫歷史 ===
  73
  74 偶爾，你需要做一些代碼控制，好比從正式的照片中去除一些人一樣，需要從歷史記錄
  75 裡面徹底的抹掉他們。例如，假設我們要發佈一個項目，但由於一些原因，項目中的某
  76 個檔案不能公開。或許我把我的信用卡號記錄在了一個文本檔案裡，而我又意外的把它
  77 加入到了這個項目中。僅僅刪除這個檔案是不夠的，因為從別的提交記錄中還是可以訪
  78 問到這個檔案。因此我們必須從所有的提交記錄中徹底刪除這個檔案。
  79
  80  $ git filter-branch --tree-filter 'rm top/secret/file' HEAD
  81
  82 參見 *git help filter-branch* ，那裡討論了這個例子並給出一個更快的方法。一般
  83 地， *filter-branch* 允許你使用一個單一命令來大範圍地更改歷史。
  84
  85 此後，+.git/refs/original+目錄描述操作之前的狀態。檢查命令filter-branch的確做
  86 了你想要做的，然後刪除此目錄，如果你想運行多次filter-branch命令。
  87
  88 最後，用你修訂過的版本替換你的項目克隆，如果你想之後和它們交互的話。
  89
  90 === 製造歷史 ===
  91
  92 [[makinghistory]]
  93 想把一個項目遷移到Git嗎？如果這個項目是在用比較有名氣的系統，那可以使用一些其
  94 他人已經寫好的腳本，把整個項目歷史記錄導出來放到Git裡。
  95
  96 否則，查一下 *git fast-import* ，這個命令會從一個特定格式的文本讀入，從頭來創
  97 建Git歷史記錄。通常可以用這個命令很快寫一個腳本運行一次，一次遷移整個項目。
  98
  99 作為一個例子，粘貼以下所列到臨時檔案，比如/tmp/history：
 100
 101 ----------------------------------
 102 commit refs/heads/master
 103 committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000
 104 data <<EOT
 105 Initial commit.
 106 EOT
 107
 108 M 100644 inline hello.c
 109 data <<EOT
 110 #include <stdio.h>
 111
 112 int main() {
 113   printf("Hello, world!\n");
 114   return 0;
 115 }
 116 EOT
 117
 118
 119 commit refs/heads/master
 120 committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800
 121 data <<EOT
 122 Replace printf() with write().
 123 EOT
 124
 125 M 100644 inline hello.c
 126 data <<EOT
 127 #include <unistd.h>
 128
 129 int main() {
 130   write(1, "Hello, world!\n", 14);
 131   return 0;
 132 }
 133 EOT
 134
 135 ----------------------------------
 136
 137 之後從這個臨時檔案創建一個Git倉庫，鍵入：
 138
 139  $ mkdir project; cd project; git init
 140  $ git fast-import --date-format=rfc2822 < /tmp/history
 141
 142 你可以從這個項目checkout出最新的版本，使用：
 143
 144  $ git checkout master .
 145
 146 命令*git fast-export* 轉換任意倉庫到 *git fast-import* 格式，你可以研究其輸
 147 出來寫導出程序， 也以可讀格式傳送倉庫。的確，這些命令可以發送倉庫文本檔案
 148 通過只接受文本的渠道。
 149
 150
 151 === 哪兒錯了？ ===
 152
 153 你剛剛發現程序裡有一個功能出錯了，而你十分確定幾個月以前它運行的很正常。天啊！
 154 這個臭蟲是從哪裡冒出來的？要是那時候能按照開發的內容進行過測試該多好啊。
 155
 156 現在說這個已經太晚了。然而，即使你過去經常提交變更，Git還是可以精確的找出問題所在：
 157
 158  $ git bisect start
 159  $ git bisect bad HEAD
 160  $ git bisect good 1b6d
 161
 162 Git從歷史記錄中檢出一個中間的狀態。在這個狀態上測試功能，如果還是有問題：
 163
 164  $ git bisect bad
 165
 166 如果可以工作了，則把"bad"替換成"good"。Git會再次幫你找到一個以確定的好版本和
 167 壞版本之間的狀態，通過這種方式縮小範圍。經過一系列的迭代，這種二分搜索會幫你
 168 找到導致這個錯誤的那次提交。一旦完成了問題定位的調查，你可以返回到原始狀態，
 169 鍵入：
 170
 171  $ git bisect reset
 172
 173 不需要手工測試每一次改動，執行如下命令可以自動的完成上面的搜索：
 174
 175  $ git bisect run my_script
 176
 177 Git使用指定命令（通常是一個一次性的腳本）的返回值來決定一次改動是否是正確的：
 178 命令退出時的代碼0代表改動是正確的，125代表要跳過對這次改動的檢查，1到127之間
 179 的其他數值代表改動是錯誤的。返回負數將會中斷整個bisect的檢查。
 180
 181 你還能做更多的事情: 幫助文檔解釋了如何展示bisects, 檢查或重放bisect的日誌,並
 182 可以通過排除對已知正確改動的檢查，得到更好的搜索速度。
 183
 184 === 誰讓事情變糟了？ ===
 185
 186 和其他許多版本控制系統一樣，Git也有一個"blame"命令：
 187
 188  $ git blame bug.c
 189
 190 這個命令可以標註出一個指定的檔案裡每一行內容的最後修改者，和最後修改時間。但
 191 不像其他版本控制系統，Git的這個操作是在綫下完成的，它只需要從本地磁碟讀取信息。
 192
 193 === 個人經驗 ===
 194
 195 在一個中心版本控制系統裡，歷史的更改是一個困難的操作，並且只有管理員才有權這
 196 麼做。沒有網絡，克隆，分支和合併都沒法做。像一些基本的操作如瀏覽歷史，或提交
 197 變更也是如此。在一些系統裡，用戶使用網絡連接僅僅是為了查看他們自己的變更，或
 198 打開檔案進行編輯。
 199
 200 中心繫統排斥離線工作，也需要更昂貴的網絡設施，特別是當開發人員增多的時候。最
 201 重要的是，所有操作都一定程度變慢，一般在用戶避免使用那些能不用則不用的高級命
 202 令時。在極端的情況下，即使是最基本的命令也會變慢。當用戶必須運行緩慢的命令的
 203 時候，由於工作流被打斷，生產力降低。
 204
 205 我有這些的一手經驗。Git是我使用的第一個版本控制系統。我很快學會適應了它，用了
 206 它提供的許多功能。我簡單地假設其他系統也是相似的：選擇一個版本控制系統應該和
 207 選擇一個編輯器或瀏覽器沒啥兩樣。
 208
 209 在我之後被迫使用中心繫統的時候，我被震驚了。我那有些脆弱的網絡沒給Git帶來大麻
 210 煩，但是當它需要像本地硬碟一樣穩定的時候，它使開發困難重重。另外，我發現我自
 211 己有選擇地避免特定的命令，以避免踏雷，這極大地影響了我，使我不能按照我喜歡的
 212 方式工作。
 213
 214 當我不得不運行一個慢的命令的時候，這種等待極大地破壞了我思緒連續性。在等待服
 215 務器通訊完成的時候，我選擇做其他的事情以度過這段時光，比如查看郵件或寫其他的
 216 文檔。當我返回我原先的工作場景的時候，這個命令早已結束，並且我還需要浪費時間
 217 試圖記起我之前正在做什麼。人類不擅長場景間的切換。
 218
 219 還有一個有意思的大眾悲劇效應：預料到網絡擁擠，為了減少將來的等待時間，每個人
 220 將比以往消費更多的頻寬在各種操作上。共同的努力加劇了擁擠，這等於是鼓勵個人下
 221 次消費更多頻寬以避免更長時間的等待。
 222
 223