git相当于hg mq？

Question

我刚开始使用Git和Mercurial一起熟悉Git.

我广泛使用Mercurial中的mq扩展来管理本地补丁,我正在寻找Git等价物.

我应该只使用Git分支吗？或者是否有更好的方法来管理本地补丁,以便轻松应用和删除补丁？

谢谢,

Answer 1

查看Git Wiki上Interfaces,Frontends And Tools页面的"Patch-management Interface layers"部分.列出了两个补丁管理界面,大致相当于Mercurials'mq' 扩展:

但是如果你不需要更高级的用法,你可以使用" git rebase --interactive "重新排序,压缩和拆分补丁.并且要针对当前版本的上游管理您的分支,"git rebase"通常就足够了.

**@ kizzx2:**`git rebase --interactive`迫使你按顺序处理整个系列.通过补丁管理界面,您可以轻松地在补丁之间来回编辑它们.您还可以查看修补程序更改的历史记录,在系列中间添加新提交,樱桃选择其他提交等. (7认同)
@Elazar:如果你早点结账,比如HEAD~2,首先你要登陆*unached HEAD*(未命名的分支); 第二,在更改提交后,例如通过修改它,之前的提交(HEAD~1,HEAD~0)**不会在它之上**(这是因为在git引用comit用于例如'parent'链接基于SHA-1的内容 - 如果提交更改,其SHA-1也会更改). (5认同)
@Elazar:使用补丁管理界面(例如Stit用于git,或mq用于Mercurial),很容易进入第4个补丁,然后是第2个补丁,然后应用所有,然后转到第3个并添加新补丁.交互式rebase意味着获得第4个补丁,然后应用所有,转到第2个补丁,然后应用所有...或使用checkout + rebase + reset,这是恕我直言,稍微难以使用. (2认同)

Answer 2

免责声明:我不是一个hg用户,所以我读过关于hg但没有太多使用它的第一手经验.

git提供了几个非常强大和灵活的工具来管理"补丁队列"样式的分支,因此对于许多基本(甚至一些非常复杂)的用例,本机git足够强大.

通常,大多数项目都保留一个中央稳定的主分支,它只获得新的提交,并且永远不会"重绕",因此主分支中的提交是固定的.

除此之外,维护者(或开发者)可以维护一个或多个基于稳定分支的正在进行的补丁(即提交)的流体分支.

典型的补丁管理活动包括:

将补丁队列重新定位到最新的稳定分支 - 使用git rebase,

将补丁队列复制到旧的maintentance分支 - 使用git branch和git rebase,

重新排序队列中的补丁 - 使用git rebase --interactive(aka git rebase -i)使用文本编辑器重新排序队列.

压缩补丁 - git rebase -i与squash指令一起使用

更改补丁或补丁提交消息 - 使用git rebase -i编辑指令(发现主题？).

任何以任何方式改变补丁的活动(即其内容,描述或父母)将创建一个新的提交,其中包含该补丁的新提交ID.旧提交可能被丢弃并在它们被提升到稳定主分支之前被定期更换的事实是使它们成为"补丁队列"而不是分支的唯一因素,但这是项目约定而不是任何物理差异在构成提交的数据中.要git它们是相同的对象.

将补丁提升为"真正的"提交只是将补丁移动到队列的前面并将其合并到主分支中.将补丁移动到队列的前面后,它与基于主分支的正常提交相同,因此将其合并只是快速转发主分支指针以指向补丁提交.

将此提交发布为"稳定"主修补程序是这样的行为:现在这是一个不会更改的提交,并且是项目的不可变历史记录的一部分.

我在一个项目中广泛使用的Mercurial Queues的一个特性是通过复制.hg/patches目录来"导出"它们.能够从回购外部存储和管理补丁是至关重要的.不可否认,这种用法非常不寻常,但是git有没有提供类似功能的东西？ (2认同)

Answer 3

只需使用一个分支,并定期将其与上游分支重新绑定.这比使用mq(我过去丢失了数据)更容易管理和更安全.

Answer 4

Git本身并没有提供这个功能.根据您的使用情况,您可能可以使用"git stash"和/或分支,但这将是非常基本的.如果人们使用git有更高级的补丁管理需求,他们似乎转向Quilt或StGit:请参阅http://git.or.cz/gitwiki/PatchManagement