我習慣於Mercurial mq extension在上游維護一組定製補丁。除了上游以外，它們可以作爲單獨的存儲庫發佈。現在在git中我使用私人分支和rebase，它運行良好，直到我想與別人分享我的補丁。發佈修補程序隊列的Git方法是什麼？
在Mercurial中，修補程序隊列是獨立的存儲庫，可以照常發佈。 Bitbucket甚至提供了修補程序隊列功能，以將其鏈接到父存儲庫。在Git中，如果我使用我的補丁發佈了私有分支，我將失去重新分配它們的能力（除非我打破合併），但補丁需要不時更新。
從another SO question我發現，在Git世界中，StGit被推薦爲mq的等價物。它與mq類似，但是如何使用StGit發佈修補程序隊列？
（stg publish似乎indended創建只是一個新的「合併友好」的分支，不發佈補丁本身）
有什麼其他的方法來發布補丁隊列中的Git？
總結答案和評論。隨着git有超過遠程上游發佈小自定義修改兩種方法：
rebase，發佈一個分支，新合併的必要到目前爲止，純補丁隊列工作流程似乎並不是可行的使用Git，但guilt似乎非常接近mq，甚至南es命令。它不允許使用版本控制（和可發佈）修補程序隊列。
AFAICT從提供的關於Mq的鏈接中，它具有與git rebase相同的發佈問題？
總而言之，我認爲發佈您的分支，並警告它是重新設計分支是您的最佳選擇。例如，這就是linux-next分支的維護方式。
它允許將版本控制下的補丁放置在_separate_存儲庫中，因此主存儲庫不受影響，並且具有補丁的存儲庫可以獨立發佈。所以它沒有與'git rebase'相同的問題，因爲它不會重寫歷史記錄（事實上，它根本不會改變它）。 – sastanin
@jetxee，好吧，這是一種註釋「不穩定」分支的方法，警告它不穩定並重新綁定？聽起來像是一件好事。 – Rawler
這是一種管理尚未提交到主線的一組修補程序的方法;可以快速應用（qpush）和不應用（qpop），重新排序並更改它們。補丁本身作爲簡單文件進行管理。當他們被應用時，整個補丁隊列看起來像是一個分支到mercurial，當他們沒有應用時，存儲庫看起來好像他們不存在。保持私人自定義，開發複雜功能（如使用rebase）或試驗是很好的。 Stit和Guilt似乎也爲Git做了同樣的事情。 – sastanin
考慮到給出的評論，似乎一個或多或少的方法相當於Mercurial的mq將使用內疚。與mq不同，內疚並不直接爲「修補程序庫」提供接口，但可以手動將.git/patches/<branch>轉換爲.git庫。
有一個名爲git-series的git擴展，它使用git來維護版本化的補丁隊列。它允許與mq類似的功能，因爲您可以維護多個系列（相當於多個hg隊列），基於反饋的重構修補程序，並將該系列提交到git。這是最接近mq，但不同的是，你應該期望一些腳射門。
您是否有理由不能簡單地發佈分支機構，理解它尚未最終確定並可能進一步重新設計？ – Cascabel
那麼，它會打破合併任何試圖從/取出它的人，對吧？那麼，如果它不允許順利升級到最後的版本，那麼將它作爲版本控制的回購發佈有什麼意義呢？ – sastanin
@jetxee：這就是關鍵：如果它可以進一步重新設計，你*不會*合併到任何重要的分支。你可以單獨獲取並處理它。 – Cascabel