2013-01-08 92 views
7

我想知道使用svn的一件事是修訂號的簡單編號。我可以很容易地看到在測試環境中部署的版本是在某個提交之前還是之後。找出是否在提交散列之前或之後檢查了git commit

使用散列作爲其提交的git,有什麼辦法來判斷是否在另一個提交之前或之後進行提交?

回答

7

事情,正如你注意到的,在Git中並不那麼簡單。特別是,「之前」和「之後」的定義需要稍微澄清一點。

如果您相信提交給您的存儲庫的人員不會弄亂時間戳,並且您已經知道這兩個提交都在同一分支上,那麼您可以比較提交的時間戳並查看哪一個更早。對每個提交使用以下命令,並比較結果。

git log -1 --format='%ci' <commit> 

使用Git,你不一定能信任時間戳,但由於不像顛覆不存在與生產它們的工作的中央存儲庫。你也不能確定兩個提交是在同一個分支上(儘管Subversion也存在這個問題)。

爲了避免這些問題,請討論一個提交是否是另一個提交的祖先,而不是它是在它之前還是之後。在下面的提交圖表,B和C是A的祖先,而B不是C的祖先也不反之亦然:

B (master) 
| C (branch) 
|/ 
A (root) 

要確定是否提交A是提交B,使用下面的命令的祖先(基於an article at git ready):

git rev-list <commitA> | grep $(git rev-parse <commitB>) 

第一部分列出了所有提交A的祖先的提交;第二部分獲取提交B的完整散列,然後在祖先列表中搜索該提交。如果看到任何輸出,則提交A是提交B的祖先。交換參數以確定提交A是否是提交B的祖先。

第二種形式比較慢,但可以絕對保證一個提交是另一個提交的祖先。

+0

那麼,是什麼時間戳,當我做混帳日誌代表-1 --format = '%CI' ?我只是想了解一個場景,當我不能相信時間戳。 – Glide

+0

@Glide:該時間戳表示提交時間。但是,因爲提交最初是在開發人員的本地存儲庫中進行的,所以如果計算機上的時鐘錯誤,或者他們使用'GIT_COMMITTER_DATE'這樣的技巧,則該時間戳可能不正確。 –

+0

嘿,這個命令可以工作,但是你對它的工作原理的說法是不正確的。 git rev-list命令實際上決定了提交B是否爲提交A的祖先。你說「第一部分列出了提交A的祖先提交的所有提交」。它顯然做了,從我做的一些測試。因此,如果您通過該列表查找提交SHA,則grep將成功IFF提交B在該祖先列表中,即提交A的祖先 - 與您所寫的內容相反。 – eeeeaaii

0

如果您使用標籤,你可以做

git describe --tags 

這會告訴你有多少自上次標籤的提交。

2

在每次提交時使用git show來查找提交的日期。沒有辦法只看哈希以確定順序,因爲它不過是一個哈希。

您可以使用自定義格式字符串來顯示您想要的內容,請檢查man pages瞭解更多信息。

git show --format="%ci" <commit> 
2

你可以得到所有從顯示亂碼,作者,日期日誌提交信息,並進行評論:

git log 

你可以拉一個特定提交從提交日誌的時間/日期。喜歡的東西:

git log -1 --format="%cd" <commit> 

的 '%的CD' 爲您提供了日誌的格式的日期,你也可以這樣做:

  • %CD:RFC2822風格
  • %的Cr:相對
  • %CT:UNIX時間戳
  • %CI:ISO 8601格式

從那裏,喲如果你需要自動化,你可以對一些腳本進行比較。

3

git rev-list --count可以提供幫助。假設110a187自帶4個提交5d41af1之前,則:

$ git rev-list --count 110a187..5d41af1 
4 
$ git rev-list --count 5d41af1..110a187 
0 

因此類似:

test $(git rev-list --count $a..$b) == 0 && \ 
     echo "$a is not an ancestor of $b" 
+0

如果@Glide意味着父/子而不是時態,那麼在提交通過從不同分支合併進入分支的情況下,這個答案更準確。 –

相關問題