第 5 章 關于歷史

Git分布式本性使得歷史可以輕易編輯。但你若篡改過去，需要小心：只重寫你獨自擁有 的那部分。正如民族間會無休止的爭論誰犯下了什么暴行一樣，如果在另一個人的克隆 里，歷史版本與你的不同，當你們的樹互操作時，你會遇到一致性方面的問題。

一些開發(fā)人員強烈地感覺歷史應該永遠不變，不好的部分也不變所有都不變。另一些覺 得代碼樹在向外發(fā)布之前，應該整得漂漂亮亮的。Git同時支持兩者的觀點。像克隆，分 支和合并一樣，重寫歷史只是Git給你的另一強大功能，至于如何明智地使用它，那是你 的事了。

我認錯

剛提交，但你期望你輸入的是一條不同的信息？那么鍵入：

$ git commit --amend

來改變上一條信息。意識到你還忘記了加一個文件？運行git add來加，然后運行上面的 命令。

希望在上次提交里包括多一點的改動？那么就做這些改動并運行：

$ git commit --amend -a

更復雜情況

假設前面的問題還要糟糕十倍。在漫長的時間里我們提交了一堆。但你不太喜歡他們的 組織方式，而且一些提交信息需要重寫。那么鍵入：

$ git rebase -i HEAD~10

并且后10個提交會出現(xiàn)在你喜愛的$EDITOR。一個例子：

pick 5c6eb73 Added repo.or.cz link
pick a311a64 Reordered analogies in "Work How You Want"
pick 100834f Added push target to Makefile

之后：

• 通過刪除行來移去提交。
• 通過為行重新排序行來重新排序提交。

• 替換?pick?使用：

  • edit?標記一個提交需要修訂。
  • reword?改變?nèi)罩拘畔ⅰ?/li>
  • squash?將一個提交與其和前一個合并。
  • fixup?將一個提交與其和前一個合并，并丟棄日志信息。

保存退出。如果你把一個提交標記為可編輯，那么運行

$ git commit --amend

否則，運行：

$ git rebase --continue

這樣盡早提交，經(jīng)常提交：你之后還可以用rebase來規(guī)整。

本地變更之后

你正在一個活躍的項目上工作。隨著時間推移，你做了幾個本地提交，然后你使用合并 與官方版本同步。在你準備好提交到中心分支之前，這個循環(huán)會重復幾次。

但現(xiàn)在你本地Git克隆摻雜了你的改動和官方改動。你更期望在變更列表里，你所有的變 更能夠連續(xù)。

這就是上面提到的?git rebase?所做的工作。在很多情況下你可以使用?--onto?標 記以避免交互。

另外參見?git help rebase?以獲取這個讓人驚奇的命令更詳細的例子。你可以拆分提 交。你甚至可以重新組織一棵樹的分支。

重寫歷史

偶爾，你需要做一些代碼控制，好比從正式的照片中去除一些人一樣，需要從歷史記錄 里面徹底的抹掉他們。例如，假設我們要發(fā)布一個項目，但由于一些原因，項目中的某 個文件不能公開。或許我把我的信用卡號記錄在了一個文本文件里，而我又意外的把它 加入到了這個項目中。僅僅刪除這個文件是不夠的，因為從別的提交記錄中還是可以訪 問到這個文件。因此我們必須從所有的提交記錄中徹底刪除這個文件。

$ git filter-branch --tree-filter 'rm top/secret/file' HEAD

參見?git help filter-branch?，那里討論了這個例子并給出一個更快的方法。一般 地，?filter-branch?允許你使用一個單一命令來大范圍地更改歷史。

此后，+.git/refs/original+目錄描述操作之前的狀態(tài)。檢查命令filter-branch的確做 了你想要做的，然后刪除此目錄，如果你想運行多次filter-branch命令。

最后，用你修訂過的版本替換你的項目克隆，如果你想之后和它們交互的話。

制造歷史

想把一個項目遷移到Git嗎？如果這個項目是在用比較有名氣的系統(tǒng)，那可以使用一些其 他人已經(jīng)寫好的腳本，把整個項目歷史記錄導出來放到Git里。

否則，查一下?git fast-import?，這個命令會從一個特定格式的文本讀入，從頭來創(chuàng) 建Git歷史記錄。通?？梢杂眠@個命令很快寫一個腳本運行一次，一次遷移整個項目。

作為一個例子，粘貼以下所列到臨時文件，比如/tmp/history：

commit refs/heads/master
committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000
data <<EOT
Initial commit.
EOT

M 100644 inline hello.c
data <<EOT
#include <stdio.h>

int main() {
  printf("Hello, world!\n");
  return 0;
}
EOT

commit refs/heads/master
committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800
data <<EOT
Replace printf() with write().
EOT

M 100644 inline hello.c
data <<EOT
#include <unistd.h>

int main() {
  write(1, "Hello, world!\n", 14);
  return 0;
}
EOT

之后從這個臨時文件創(chuàng)建一個Git倉庫，鍵入：

$ mkdir project; cd project; git init
$ git fast-import --date-format=rfc2822 < /tmp/history

你可以從這個項目checkout出最新的版本，使用：

$ git checkout master .

命令git fast-export?轉(zhuǎn)換任意倉庫到?git fast-import?格式，你可以研究其輸 出來寫導出程序， 也以可讀格式傳送倉庫。的確，這些命令可以發(fā)送倉庫文本文件 通過只接受文本的渠道。

哪兒錯了？

你剛剛發(fā)現(xiàn)程序里有一個功能出錯了，而你十分確定幾個月以前它運行的很正常。天??！ 這個臭蟲是從哪里冒出來的？要是那時候能按照開發(fā)的內(nèi)容進行過測試該多好啊。

現(xiàn)在說這個已經(jīng)太晚了。然而，即使你過去經(jīng)常提交變更，Git還是可以精確的找出問題所在：

$ git bisect start
$ git bisect bad HEAD
$ git bisect good 1b6d

Git從歷史記錄中檢出一個中間的狀態(tài)。在這個狀態(tài)上測試功能，如果還是有問題：

$ git bisect bad

如果可以工作了，則把"bad"替換成"good"。Git會再次幫你找到一個以確定的好版本和 壞版本之間的狀態(tài)，通過這種方式縮小范圍。經(jīng)過一系列的迭代，這種二分搜索會幫你 找到導致這個錯誤的那次提交。一旦完成了問題定位的調(diào)查，你可以返回到原始狀態(tài)， 鍵入：

$ git bisect reset

不需要手工測試每一次改動，執(zhí)行如下命令可以自動的完成上面的搜索：

$ git bisect run my_script

Git使用指定命令（通常是一個一次性的腳本）的返回值來決定一次改動是否是正確的： 命令退出時的代碼0代表改動是正確的，125代表要跳過對這次改動的檢查，1到127之間 的其他數(shù)值代表改動是錯誤的。返回負數(shù)將會中斷整個bisect的檢查。

你還能做更多的事情: 幫助文檔解釋了如何展示bisects, 檢查或重放bisect的日志,并 可以通過排除對已知正確改動的檢查，得到更好的搜索速度。

誰讓事情變糟了？

和其他許多版本控制系統(tǒng)一樣，Git也有一個"blame"命令：

$ git blame bug.c

這個命令可以標注出一個指定的文件里每一行內(nèi)容的最后修改者，和最后修改時間。但 不像其他版本控制系統(tǒng)，Git的這個操作是在線下完成的，它只需要從本地磁盤讀取信息。

個人經(jīng)驗

在一個中心版本控制系統(tǒng)里，歷史的更改是一個困難的操作，并且只有管理員才有權這 么做。沒有網(wǎng)絡，克隆，分支和合并都沒法做。像一些基本的操作如瀏覽歷史，或提交 變更也是如此。在一些系統(tǒng)里，用戶使用網(wǎng)絡連接僅僅是為了查看他們自己的變更，或 打開文件進行編輯。

中心系統(tǒng)排斥離線工作，也需要更昂貴的網(wǎng)絡設施，特別是當開發(fā)人員增多的時候。最 重要的是，所有操作都一定程度變慢，一般在用戶避免使用那些能不用則不用的高級命 令時。在極端的情況下，即使是最基本的命令也會變慢。當用戶必須運行緩慢的命令的 時候，由于工作流被打斷，生產(chǎn)力降低。

我有這些的一手經(jīng)驗。Git是我使用的第一個版本控制系統(tǒng)。我很快學會適應了它，用了 它提供的許多功能。我簡單地假設其他系統(tǒng)也是相似的：選擇一個版本控制系統(tǒng)應該和 選擇一個編輯器或瀏覽器沒啥兩樣。

在我之后被迫使用中心系統(tǒng)的時候，我被震驚了。我那有些脆弱的網(wǎng)絡沒給Git帶來大麻 煩，但是當它需要像本地硬盤一樣穩(wěn)定的時候，它使開發(fā)困難重重。另外，我發(fā)現(xiàn)我自 己有選擇地避免特定的命令，以避免踏雷，這極大地影響了我，使我不能按照我喜歡的 方式工作。

當我不得不運行一個慢的命令的時候，這種等待極大地破壞了我思緒連續(xù)性。在等待服 務器通訊完成的時候，我選擇做其他的事情以度過這段時光，比如查看郵件或?qū)懫渌?文檔。當我返回我原先的工作場景的時候，這個命令早已結(jié)束，并且我還需要浪費時間 試圖記起我之前正在做什么。人類不擅長場景間的切換。

還有一個有意思的大眾悲劇效應：預料到網(wǎng)絡擁擠，為了減少將來的等待時間，每個人 將比以往消費更多的帶寬在各種操作上。共同的努力加劇了擁擠，這等于是鼓勵個人下 次消費更多帶寬以避免更長時間的等待。