我习惯于 Mercurialmq扩展以在上游维护一组自定义补丁。除了上游之外，它们可以作为单独的存储库发布。现在在 git 中，我使用私有分支和rebase，它运行良好，直到我想与其他人共享我的补丁。
在 Mercurial 中，补丁队列是一个独立的存储库，可以像往常一样发布。Bitbucket 甚至提供了一个补丁队列功能将其链接到父存储库。在 Git 中，如果我用我的补丁发布了一个私有分支，我将无法再对它们进行变基（除非我中断合并），但补丁需要不时更新。
从我发现的另一个 SO 问题中，在 Git 世界中，StGit 被提议作为mq. 它的使用类似于mq，但是如何使用 StGit 发布补丁队列？
（stg publish似乎旨在创建一个新的“合并友好”分支，而不是发布补丁本身）
在 Git 中发布补丁队列的其他方法是什么？
总结答案和评论。有git两种方法可以在远程上游发布小的自定义修改：
rebase，根据需要发布一个分支和新的合并到目前为止，纯补丁队列工作流程似乎不适用于 git，但guilt似乎非常接近mq，甚至是命令的名称。它不允许版本控制（和可发布）的补丁队列。
考虑到给出的评论，似乎或多或少等同于 Mercurial 的 mq 的方法是使用内疚。与 mq 不同，guilt 不直接为“补丁存储库”提供接口，但您可以.git/patches/<branch>手动将其转换为 .git 存储库。
有一个名为的 git 扩展git-series，它使用 git 来维护版本化的补丁队列。它允许类似的功能mq，因为您可以维护多个系列（相当于多个 hg 队列），根据反馈重构补丁，并将系列提交到 git。它最接近mq，但又足够不同，以至于您应该期待一些脚射。
来自提供的关于 Mq 的链接中的 AFAICT，它与 git rebase 有大约相同的发布问题吗？
总而言之，我认为发布你的分支，并警告它是一个变基分支是你最好的选择。例如，这就是 linux-next 分支的维护方式。