人類可讀/可比較的git變更ID

某些版本控制系統（例如Perforce）將CL保留爲簡單整數，因此在同一分支上查看兩個不同的CL，很容易理解哪個CL先被合併。但是，在Git的情況下，CL/short CL是很長的十六進制字符串，這很容易被人眼所媲美。有什麼辦法擺脫這個問題嗎？人類可讀/可比較的git變更ID

這就是爲什麼Git中的每個提交都有一個與它關聯的_message_，並且可能還有一個標記。 –

不知道爲什麼有人投票失敗。 –

這不是我，它是值得的。 –

恐怕不是。系統的分佈式特性排除了單調增加的「修訂號」。如果您和地球另一端的其他人決定同時提交（不推送）修補程序，誰的版本號爲n，誰是n+1？只有當有一箇中央服務器可以分配修訂號碼時，才能進行這種同步。這是支付分發費用的代價。

然而，雖然沒有技術解決方案，但有社會解決方案。良好的分支名稱，適當的標記可幫助您瞭解項目的進展情況。 git branch --merged和--no-merged會給你詳細說明什麼分支合併，哪些分支不合並。

2017-02-13 05:19:54

（這是正確的答案，並被upvoted。）還值得指出的是，當你使用標籤，你也可以使用'git describe'。這試圖計算一個有點人性化的數字，產生' - -g '的輸出，這是自從''以來提交的線性計數的近似值。在評論中描述太多空間的限制下，「」的值將會保持穩定。 – torek

描述，分支，標籤和其他一些東西的輸出都是所謂[treeish]的示例（http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git#18605496 ）s在git中。 –

實際上它們是「提交」的，但當然任何標識提交的地方，只要需要樹，都會解析爲樹。一些命令，比如'git show'，將訪問提交;在這種情況下，您可以使用gitrevisions的'^ {tree}'後綴強制將提交ID轉換爲相應的樹ID。 – torek

不，git的SHA-1哈希是一個40個字符的字符串。它是基於文件的內容計算的。而git olny在數據庫中存儲SHA-1。所以對人眼來說這是不可讀的。

如果要查看git的歷史記錄，可以清楚地查看git log --oneline --decorate --graph --all。

2017-02-13 05:08:58

回答