我一直在使用Git大約一年，並認爲它太棒了，但我剛剛開始了第二個版本的項目併爲它啓動了一個新分支。我正在努力處理未來事情的最佳方式。git - 合併時跳過特定提交
我有兩個分支叫做master10（for v1）和master20（for v2）。我一直在分支master10上對v1進行bug修復，並開發master20的新功能。無論何時我進行錯誤修復，我都會通過檢查master20並執行git merge master10將它合併到v2中。到現在爲止還挺好。
現在，我已經對v1做了一些改變，我不想在v2中進行修改，但是我想繼續合併其他bug修復。我如何告訴Git跳過那個特定的提交（或一系列提交），但是我仍然希望合併其他錯誤修復。
我以爲git rebase可能是我需要的，但閱讀文檔和我的頭幾乎爆炸。
我想我想要的就像是一個「git sync」命令，告訴git兩個分支現在處於同步狀態，將來只會合併來自此同步點的提交。
任何幫助表示讚賞。
例如，如果您想要將分支「maint」中的大部分但不是全部的提交合併到「master」，則可以執行此操作。它需要一些工作----如上所述，通常的用例是合併來自分支的所有內容---但有時候會發生，你對發佈版本進行了更改，而這些發佈版本不應該被整合回來（也許該代碼的已經被主人取代了），那麼你如何表現呢？這裏去...
因此，讓我們假設maint已經應用了5個改變，其中一個（maint〜3）不會被合併回主，儘管所有其他應該是。你需要分三步進行：實際上將所有內容合併到一個之前，告訴git將maint〜3標記爲合併，即使不合並，然後合併其餘部分。神奇的是：
bash <master>$ git merge maint~4
bash <master>$ git merge -s ours maint~3
bash <master>$ git merge maint
第一個命令合併一切之前你的麻煩MAINT提交到主。默認合併日誌消息將解釋您正在合併「分支」maint'（早期部分）「。第二個命令合併麻煩的maint〜3提交，但是「-s我們的」選項告訴git使用一個特殊的「合併策略」，實際上，它通過簡單地保持你合併到的樹並忽略您正在完全合併的提交。但它仍然以HEAD和maint〜3作爲父項進行新的合併提交，因此修訂圖現在說明maint〜3被合併。所以實際上你可能也想使用-m選項來'git merge'，以解釋那個maint〜3 commit實際上被忽略了！
最終的命令簡單地將maint（maint〜2..maint）的其餘部分合併到master中，以便您再次同步。
創建第三個分支，用於在master10中但不在master20中進行的更改。始終將master10視爲您的「主人」，這是所有人中最穩定的部門。該分行的所有其他分行都希望始終保持同步。
我想這可以工作，但我已經讓自己進入這個狀態，第三個分支可能會讓我更加困惑。 :) – 2009-04-08 06:08:20
承諾包括祖先。如果不合並之前的提交，你不能合併提交。
當然，你可以挑選它們。當您有一個處於維護模式的分支時，這是一個很好的流程。
謝謝，櫻桃採摘會做的工作。不如我期待的那麼好，但它會做。 – 2009-04-08 06:06:57
恕我直言，最合乎邏輯的事情是，把合併一切，然後用git revert（commit_you_dont_want）將其刪除。
例子：
git merge master
git revert 12345678
如果您有多個 「到忽略」 承諾，還是想編輯回覆消息：
git merge master
git revert -n 123456
git revert -n abcdef
git commit -m "... Except commits 123456 and abcdef"
然後你的歷史可能看起來像：
| ... Except 123456 and abcdef
|\ Merge branch 'master' into 'your_branch'
如果您有涉及這些「忽略」提交的衝突，則可以使用：
git merge master -X ours
因此，您的版本將持續在另一個版本上。即使沒有錯誤消息，您仍然可以「還原」那些不需要的提交，因爲它們可能有其他更改沒有衝突，並且您仍然不需要它們。
如果你有衝突包含不僅僅是「忽略」提交，你應該手動解決它們，你可能不得不在恢復過程中再次解決它們。
一種廣告給我的project，它基本上包裝了@araqnid描述的過程。
這是一種輔助性的，介紹如下GIT流量：
從項目頁面引述：
取決於它可能具有的維護或與主分支一起 客戶特定的分支流程。這些 分支也被稱爲LTS分支。
通常情況下，熱修復會進入bug報告的分支，然後提交被合併回主分支。
一般做法是，你想看到一個特定 分支和主之間有明顯的增量，瞭解掌握是否包含所有 特性和錯誤修正各分公司與 完全同步的主人，即。
但是有時您不希望特別提交，因爲它們是 客戶特定的，並且其他用戶不可見。或者你的 主分支分歧太大，它需要完全不同的 方法來解決這個問題，或者甚至更好，問題不再存在在那裏 。
另外，如果從主站挑選維護分支 ，則所產生的提交將被阻塞在主站中。
但是我不知道這是不是有點危險：什麼是桅杆〜3絕對不能忽視，而是簡單地推遲？使用你的解決方案，任何後續的git merge maint都不會合並回桅杆〜3。 – VonC 2009-04-08 17:09:39
對於推遲的提交，我會創建一個「sub-branch」，完成你所描述的操作（包括git merge -s我們的maint〜3），然後合併從sub-branch到master的所有內容。我相信未來的「git merge maint」會將這段時間合併爲「mast〜3」 – VonC 2009-04-08 17:11:29