我想使用git hash來緩存破壞目的。Git：爲緩存破壞目的檢索short commit hash
我的部署腳本會在git中尋找特定的文件，並且會使用來自上次提交的文件發生更改的短版本散列。這意味着每個文件的緩存清除字符串僅在必要時纔會更改。
到目前爲止，我有下面的命令，這是接近但不完全正確：
git log -n 1 --abbrev-commit --pretty=oneline htdocs/js/sample.js
返回：
21b1991 Commit message here
我可以解析該字符串提交哈希，但我如果可能，寧可不這樣做。
我想作git的回報：
21b1991
我當然喜歡的解決方案，繼續工作應啓動的git一旦發出命令返回不同長度的散列。我也沒有反對使用完整的散列，但我不認爲這是必要的。
部署將基於git，並在Ubuntu 12.04 TLS系統上進行。
對此提出建議？
嘗試--pretty=format:%h，而不是--abbrev-commit --pretty=oneline
例如
git log -n 1 --pretty=format:%h htdocs/js/sample.js
您可以用awk此：
git log -n 1 --abbrev-commit --pretty=oneline htdocs/js/sample.js | awk '{print $1}'
你應該記住，短提交哈希的尺寸可以變化，這取決於有多少承諾你有你的歷史 - 你支付在代碼中使用了完整的哈希值的價格相差很小，而與完全哈希你保證總是指向正確的文件。
我將短散列看作是對我們可憐的小腦子開發者的一種方便，而不是程序代碼應該用來保存幾個字節的東西。
這不是問題，標記的答案將始終返回整個短散列。 – michaelward82 2013-02-15 20:54:33
哈希需要滿足的唯一標準是特定文件的提交之間重複性低的可能性。簡短的哈希似乎是非常合適的，除非你有數學證明否則。 – michaelward82 2013-02-15 21:15:07
此外，git返回的短代碼保證是唯一的（在執行時），即使git必須返回整個sha1字符串才能實現此目的。見http://git-scm.com/book/ch6-1.html – michaelward82 2013-02-15 21:23:14
完全按照我的意願工作。謝謝。 – michaelward82 2013-02-15 20:35:44