Git：將分支合併到主分支或主分支

Question

我想知道如果我先將主合併到另一個分支中，然後將它合併回主。

假設我創建了以下分支，每一個單獨的承諾：

  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" 

現在我想合併。通常情況下，我更喜歡先合併掌握到x，然後對x合併到主：

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

這樣合併到master，確保我總是有一個正常運作的主分支之前，我可以測試的東西。據我所知，沒有任何功能上的差別，相比於直接合並x轉換成主：

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

在實踐中，我經常會遇到，似乎完全合併到主然而庫。我的方法有什麼缺點嗎？任何我不應該這樣做的原因？

Answer 1

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

這是一個偉大的練習合併主副本到您的分支合併之前。如果其他人犯了破壞剛纔實現的功能的東西（正如你指出的那樣）？或者如果某人修改了您所做的相同代碼並導致了可能的合併衝突？我實際上建議非常頻繁地將主人合併回分支。這不僅會讓你不得不花費一天半的時間來解決合併衝突（儘管這可能表明你的分支機構太大了，但這是另一回事），但它也可以讓你隨着項目的變化而保持一致演變。

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

所以，是的，在你合併之前從主人合併回來，並且你可以以其他方式經常合併。如果你使用GitHub上，我甚至鼓勵使用新的受保護的分支功能來合併之前執行與主更新分支：