git 相当于 hg mq 吗？
我刚刚开始将 Git 与 Mercurial 一起使用来熟悉 Git。
我广泛使用 Mercurial 中的 mq 扩展来管理本地补丁，并且我正在寻找 Git 等效项。
我应该只使用 Git 分支吗？ 或者是否有更好的方法来管理本地补丁，以便轻松应用和删除补丁？
谢谢，
I just started using Git alongside Mercurial to familiarize myself with Git.
I use the mq extension in Mercurial extensively to manage local patches, and I'm looking for a Git equivalent.
Should I just use Git branch? Or are there better ways to manage local patches that enable easily applying and removing the patches?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
查看接口、前端和工具<的“补丁管理接口层”部分< Git Wiki 上的 /a> 页面。 列出了两个补丁管理接口，大致相当于 Mercurials 'mq' 扩展：
但如果你不需要更高级的用法，你可以使用 "git rebase --interactive" 来重新排序、压缩和分割补丁。 要根据上游的当前版本管理您的分支，“git rebase”通常就足够了。
Check out "Patch-management Interface layers" section of Interfaces, Frontends And Tools page on Git Wiki. There are listed two patch management interfaces, roughly equivalent to Mercurials 'mq' extension:
But if you don't need more advanced usage, you can use instead "git rebase --interactive" to reorder, squash and split patches. And to manage your branch against current version of upstream, "git rebase" usually would suffice.
免责声明：我不是 hg 用户，所以我读过有关 hg 的内容，但没有太多使用它的第一手经验。
git 提供了几个非常强大且灵活的工具，用于以“补丁队列”方式管理分支，因此对于许多基本（甚至一些相当复杂）的用例，本机 git 足够强大。
通常，大多数项目都会保留一个中央稳定的主分支，该分支只会获得新的提交，并且永远不会“回滚”，因此主分支中的提交是固定的。
除此之外，维护者（或开发人员）可以维护一个或多个基于稳定分支的正在进行的补丁（即提交）的流动分支。
典型的补丁管理活动包括：
将补丁队列变基到最新的稳定分支 - 使用 git rebase ，
将补丁队列复制到旧的维护分支 - 使用 gitbranch 和
>git rebase，对队列中的补丁重新排序 - 使用文本编辑器使用
git rebase --interactive（又名git rebase -i）对队列进行重新排序。压缩补丁 - 将
git rebase -i与 squash 指令一起使用，更改补丁或补丁提交消息 - 将
git rebase -i（发现主题？）与 edit 指令一起使用。任何以任何方式（即其内容、描述或来源）更改补丁的活动都将为该补丁创建一个具有新提交 ID 的新提交。 事实上，旧的提交在升级到稳定的主分支之前可能会被丢弃并定期替换，这是使它们成为“补丁队列”而不是分支的唯一原因，但这是一个项目约定，而不是任何物理差异在构成提交的数据中。 对于 git 来说，它们是相同的对象。
要将补丁提升为“真正的”提交，只需将补丁移动到队列的前面并将其合并到主分支中。 将补丁移动到队列的前面后，它与基于主分支的正常提交相同，因此合并它只是将主分支指针快进指向补丁提交。
将此提交发布为“稳定”主补丁的行为表明：现在这是一个不会更改的提交，并且是项目不可变历史记录的一部分。
Disclaimer: I'm not an hg user, so I have read about hg but don't have much first hand experience of using it.
git provides several very powerful and flexible tools for managing branches in a 'patch queue' style so for many basic (and even some quite complex) use cases, native git is sufficiently powerful.
Typically, most projects keep a central stable master branch which only gains new commits and is never 'rewound' so commits in the master branch are fixed.
On top of this a maintainer (or a developer) may maintain one or more fluid branches of work-in-progress patches (i.e. commits) which are based on the stable branch.
Typical patch managing activities include:
rebasing the patch queue onto the lastest stable branch - use
git rebase,duplicating the patch queue onto an old maintentance branch - use
git branchandgit rebase,reordering patches in the queue - use
git rebase --interactive(akagit rebase -i) using a text editor to reorder the queue.squashing patches - use
git rebase -iwith the squash directivealtering patches or patch commit messages - use
git rebase -i(spot a theme?) with the edit directive.Any activity that alters a patch in any way (i.e. its contents, description or parentage) will create a new commit with a new commit id for that patch. The fact that the old commits may be thrown away and replaced regularly before they are promoted to the stable master branch is the only thing that makes them a 'patch queue' rather than a branch, but this is a project convention rather than any physical difference in the data that makes up the commits. To git they are identical objects.
To promote a patch to a 'real' commit is just moving the patch to the front of the queue and merging it into the master branch. After moving the patch to the front of the queue, it is just the same as a normal commit based on the master branch, so merging it just fast-forwards the master branch pointer to point at the patch commit.
Publishing this commit as a 'stable' master patch is the act that says: this is now a commit that will not change and is part of the immutable history of the project.
只需使用一个分支并定期根据您的上游分支重新建立基础即可。 这比使用 mq 更容易管理，也更安全（我过去曾丢失过 mq 数据）。
Just use a branch and rebase it against your upstream branch regularly. This is both easier to manage and safer than using mq (to which I've lost data in the past).
Git 本身并没有真正提供这个功能。 根据您的用途，您可能可以使用“git stash”和/或分支，但这将是非常基本的。 如果人们对 git 有更高级的补丁管理需求，他们似乎会转向 Quilt 或 StGit：请参阅 http:// git.or.cz/gitwiki/PatchManagement
Git doesn't really provide this feature itself. Depending on your uses, you might be able to get by with "git stash" and/or branches, but it'll be pretty basic. If people have more advanced patch management needs with git, they seem to turn to Quilt or StGit: see http://git.or.cz/gitwiki/PatchManagement