Git：將分支合並為master，或者master轉換為分支

Question

我想知道我是否犯了一個錯誤，首先將master合並到另一個分支，然后將它合並回master。

假設我創建了以下分支，每個分支都有一個單獨的提交：

            mkdir git_merging
            cd git_merging/
            git init
            touch on_master
            git add .
            git commit -m "Initial commit on master"

            git checkout -b x
            touch on_branch_x
            git add .
            git commit -m "Initial commit on branch x"

            git checkout master
            touch on_master_again
            git add .
            git commit -m "Commit on master after branching"

現在我想合並。 通常，我更喜歡先將master合並到x中，然后將x合並到master中：

            git checkout x
            git merge -m "Merge master into x" master 
            echo "test results"
            git checkout master 
            git merge x

這樣我就可以在合並回master之前測試一些東西，確保我總是有一個正常運行的master分支。 據我所知，與將x直接合並到master中相比，沒有功能差異：

            git merge -m "Merge x into master" x
            git checkout x 
            git merge master 

實際上，我經常會遇到似乎完全合並回主人的存儲庫。 我的方法有什么缺點嗎？ 我不應該這樣做的任何理由？

Answer 1

這是一個非常主觀的問題，但我會給它一個通行證，因為我認為我可以提出一個相當客觀的答案。

在合並之前將master重新合並到您的分支中是一種很好的做法。 如果其他人犯下了破壞您剛剛實施的功能的內容（正如您所指出的），該怎么辦？ 或者如果有人修改了您所做的相同代碼，並導致可能的合並沖突怎么辦？ 我實際上建議非常頻繁地將主人合並到你的分支中。 這不僅可以防止您花費一天半的時間來解決合並沖突（但是，這可能表明您的分支機構太大，但這是另一個故事），但它也會讓您在項目更改時保持一致演變。

也許有人會說，你應該重訂上主的頂部您的提交。 我的簡短版本是：我鼓勵人們在開發過程的早期就開啟拉取請求，即使沒有完成某項功能。 這意味着您可能會將代碼推送到遠程服務器（例如GitHub）。 為了重新提交你的提交，你必須推送重寫的git歷史記錄，並強制推送。 強制推送是一個糟糕的工作流決策，應該避免，因為它可能會導致（幾乎）永久性損壞您的提交歷史記錄。

所以是的，在您查看合並之前從主服務器合並，並且盡可能經常。 如果您使用GitHub，我甚至鼓勵使用新的受保護分支功能在合並之前強制更新master分支：