git staging area 的價值

之前用 mercurial 時一直很納悶, 為啥 git 的愛好者都如此推崇 staging area, 但我怎麼看就是看不懂, mercurial 沒這東西用起來也沒特別困擾, 反而要和別人解釋 staging area 時還會一直說不清楚 (畢竟自己也沒搞懂它的價值 ...)。

看到《The Thing About Git》總算解開我多年來 (遠目...) 的疑惑, 要配合「只想 commit 檔案內部份修改」的情境才會突顯它的價值。

該文有範例說明, 有時我們會同時改到不同東西, 好死不死, 兩個東西的修改在同一個檔案裡。這時有幾個選擇:

• 就給它 commit 下去, 在 commit log 裡順帶一提多 commit 的東西
• 兩個功能一起 commit 進去, commit log 寫長一點, commit 內容比較雜
• 回去原本的檔案「取消」不想 commit 的修改, 再回來 commit

身為一名良好市民, 大部份時候我是選第三個方案, 但是做得很辛苦。mercurial 好像有 extension 可以只 commit 部份內容 (hunk-by-hunk commit), 不過我懶得找。我後來的作法是:

• 用 thg 的 commit
• 在 commit 視窗裡針對目標檔案按 "open shelve tool"
• hunk-by-hunk 地 shelve 不想 commit 的內容
• commit
• unshelve all

還過得去就是了。

但是有 staging area 的話, 有不同的選擇。先 hunk-by-hunk 地將準備 commit 的內容加到 staging area (git add --patch), 接下來比對 repository 和 staging area 確認要 commit 的內容, 同時還可回頭比對 staging area 和 working directory 確定沒有漏東西。和 shelve 的作法相比, 比較直覺一些。

2012-02-18 Update

看到邱提到《A Git User's Guide to Mercurial Queues》 (ref.), 裡面有說明用 MQ 做到「多重 staring area」的效果, 看起來挺實用的。更新一個涉及多個模組的功能時, 個人偏向依各模組拆開 commit, 比較易讀。配合 MQ 可以更直覺地折解更新成多個 patch, 並保有隨時更新的彈性, 最後再一起 commit 成多個 changesets。