如何防止特定分支在git中合並？

Question

我們有一個master分支，用於存放已發布的生產代碼，一個dev分支，用於存放測試服務器的代碼，以及每個開發人員認為合適的各種功能分支（從master分支）。

隨着時間的流逝， dev部門與master有所不同。 另外，那里還有一些不正確的合並，使部分代碼混亂。 我們已經嘗試過幾次重置（force-push） dev者使其與master相同。 可以這么說，要重新開始。

不幸的是，這不會持續很長時間。 遲早有人將舊dev合並到新dev ，並帶回了所有混亂。 我懷疑這甚至可能會自動發生，其中一個幼稚的git pull默默地合並新舊分支頭。

是否可以通過服務器端提交掛鈎防止這種情況？ 如果合並了錯誤的提交，是否會拒絕接受git push ？

Answer 1

Git Hooks有可能。 將以下POC腳本放在遠程（服務器端）存儲庫上的.git/hooks/pre-receive ，並為其授予執行權限。

配置您要保護的分支，例如master

$ git config hooks.protected-branch.refs master

文件：.git / hooks / pre-receive

#!/bin/sh

read old_value new_value ref_name

refs=$(git config hooks.protected-branch.refs)

for ref in $refs; do
    if [ "$ref_name" == "refs/heads/$ref" ]; then
        if [ "$old_value" == "0000000000000000000000000000000000000000" ]; then
            continue
        fi

        if ! git merge-base --is-ancestor "$ref_name" "$new_value"; then
            echo "$ref_name is protected branch"
            exit 1
        fi
    fi
done

當您嘗試通過強制推送重置master ，您將獲得類似以下的輸出：

Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 920 bytes | 153.00 KiB/s, done.
Total 12 (delta 4), reused 0 (delta 0)
remote: refs/heads/master is protected branch
To ../demo
 ! [remote rejected]   master -> master (pre-receive hook declined)
error: failed to push some refs to '../demo

Answer 2

GitHub具有一項稱為“受保護的分支”的功能，該功能使存儲庫管理員可以禁用對特定分支的強制推送。

除了阻止強制推送外，受保護的分支還可以進行必需的狀態檢查。

有關更多信息...請檢查https://blog.github.com/2015-09-03-protected-branches-and-required-status-checks/

Answer 3

遲早有人將舊開發人員合並到新開發人員中，並帶回了所有混亂。

使用默認的git pull行為時，這是一個常見問題。 為了避免這種情況，可以將git pull配置為默認使用rebase而不是merge 。 也就是說，要將當前分支重新建立到遠程分支上，而不是合並它：

git config pull.rebase interactive

從git-config手冊頁：

pull.rebase

如果為true ，則在運行“ git pull”時，將重設分支到獲取的分支之上，而不是從默認遠程合並默認分支。 請參閱“分支..rebase”以在每個分支的基礎上進行設置。

當preserve ，還要將--preserve-merges傳遞給git rebase，這樣本地提交的合並提交將不會通過運行git pull進行展平。

當該值是interactive ，rebase以交互模式運行。

注意：這可能是危險的操作； 除非您了解其中的含義，否則不要使用它（有關詳細信息，請參見git-rebase（1））。

這樣，每當遠程分支被重寫（使用push -f ）時，無論誰拉動，都將負責識別和刪除在重建基准期間的“舊”提交。 這將在每個分支上產生干凈的歷史記錄（即：沒有“舊”版本的合並）。