GIT掛鉤阻止實驗分支被推送到發佈版或主分支

我們在我們的工作流程中有三個主要分支。GIT掛鉤阻止實驗分支被推送到發佈版或主分支

TEST（試驗），RELEASE（功能將在下一個版本）和MASTER（只發布）

我們從RELEASE功能分支，首先合併功能分支測試，如果他們確定，合併這些批准功能分支到RELEASE。

我的問題是：由於TEST分支包含一些我們將不會發布的提交/功能，我們不希望它誤合併（或故意）合併到RELEASE或MASTER中。

我在某處讀到了防止在本地存儲庫中合併的可能性或可行性，我認爲這不會解決我的問題。

因此，當新ref在其提交日誌中包含TEST分支的特定提交ID時，可能最好防止更新主存儲庫中的MASTER或RELEASE分支引用（通過推送到原點）。

因此，我只會對TEST分支進行特定的提交，並記錄它的提交ID。

每當有人想推動主或釋放分支，我會檢查這個推動是否會更新我的refs/heads/master或refs/heads/RELEASE到一個提交引用，其中包含那個壞的提交ID在其歷史和中止。

因爲我不是BASH或GIT master，有沒有人有這樣的更新鉤子，我們可以應用到我們的主要存儲庫？

來源

2012-11-14 Volkan Ceylan

這是一個更新鉤子，應該爲此工作。您可以通過給予標籤，如forbidden/junk或forbidden/debugging來指定不應允許進入RELEASE或MASTER分支的提交。如果找到禁止的提交，則標記名稱將包含在拒絕消息中。

refname="$1" 
oldrev="$2" 
newrev="$3" 
case "$refname" in 
    refs/heads/RELEASE|refs/heads/MASTER) 
    for forbidden in $(git tag -l 'forbidden/*'); do 
     if [ $(git merge-base "$forbidden" $newrev) = $(git rev-parse "$forbidden") ]; then 
     echo "Push to $refname contains commit $forbidden" >&2 
     exit 1 
     fi 
    done 
    ;; 
esac 
exit 0

需要注意的是，如果你有一個包含若干問題的承諾，你必須創建一個forbidden標記爲最早的企業之一，而不僅僅是最終在系列犯的一個分支。因此，如果歷史記錄類似於B,C和D都被禁止，則僅將標記D標記爲禁止不會阻止E合併並將B與它一起。

A---B----C----D 
    \ 
     ---E

來源

2012-11-14 18:14:49 qqx

謝謝你看起來很有希望，我會測試它並讓你知道。澄清，我應該適用於掌握回購權？你是否認爲我會遇到像其他答案中所述的「平臺」問題，如果我只合併到TEST中，並且永遠不會合並回來或從TEST中分支出來？ –

是的，應該將其安裝爲主存儲庫上的'update'鉤子。由於你的'TEST'分支接收了很多合併，所以我沒有預料到會有問題，但從來沒有被合併過。 – qqx

如果我在TEST分支中標記了一個很舊的提交（例如合併提交，如合併的'feature-abcd分支進入TEST'），那麼它不在RELEASE分支中。我仍然必須標記新的提交（它們通常也只是合併提交），就像你寫的那樣被禁止了嗎？ –

此問題需要作爲管理問題解決，而不是自動化問題。問題在於TEST可能包含來自其他兩個分支的大部分提交。所以你將無法有效識別來自TEST的提交。例如，在我們的環境中，我們會定期更新實驗分支，並使用來自主分支的更新提交。

您需要有人擔任發佈經理，以確保如果某件不好的事情被合併到主服務器中，那麼在問題解決之前它不會被部署。問題本身並不一定是錯誤的合併。問題在於部署錯誤的合併。

您可能會覺得有用的一種工具是Bitbucket.org，他們有一個基本的提交審批機制。這只是建議性的內容，但可能有助於您追蹤哪些提交已被批准，哪些可能被錯誤合併。

來源

2012-11-14 15:05:49 platforms

是的，它會更好地得到它的管理，但我們還沒有這樣一個版本mgr（我們應該！），並使用基於網絡共享的主回購。我很難說服團隊與GIT交換TFS，並且必須對TFS應用類似的工作流程。現在，因爲他們都是GIT的新秀，所以我必須防止他們錯誤地推動，因爲一旦有人推動，而其他人在我注意到之前就拉動，那麼解決問題將非常困難。 –

GIT掛鉤阻止實驗分支被推送到發佈版或主分支

回答

相關問題