我刚开始使用Git和Mercurial一起熟悉Git。
我在Mercurial中广泛使用mq扩展来管理本地补丁,我正在寻找Git等价物。
我应该使用Git分支吗?或者是否有更好的方法来管理本地补丁,以便轻松应用和删除补丁?
谢谢,
答案 0 :(得分:31)
查看Git Wiki上Interfaces, Frontends And Tools页面的“补丁管理界面层”部分。列出了两个补丁管理界面,大致相当于Mercurials的mq'扩展:
但是,如果您不需要更高级的用法,则可以使用“git rebase --interactive”重新排序,压缩和拆分补丁。并且要针对当前版本的上游管理您的分支,“git rebase”通常就足够了。
答案 1 :(得分:31)
免责声明:我不是一名hg用户,所以我读过有关hg但没有太多使用它的第一手经验。
git提供了几个非常强大而灵活的工具,用于以“补丁队列”方式管理分支,因此对于许多基本(甚至一些非常复杂)的用例,本机git足够强大。
通常情况下,大多数项目都会保留一个中央稳定的主分支,它只获得新的提交而且永远不会“重绕”,因此主分支中的提交是固定的。
除此之外,维护者(或开发人员)可以维护一个或多个基于稳定分支的正在进行的补丁(即提交)的流体分支。
典型的补丁管理活动包括:
将补丁队列重新定位到最新的稳定分支 - 使用git rebase
,
将补丁队列复制到旧的maintentance分支 - 使用git branch
和git rebase
,
重新排序队列中的补丁 - 使用git rebase --interactive
(又名git rebase -i
)使用文本编辑器重新排序队列。
压缩补丁 - 将git rebase -i
与squash指令一起使用
更改补丁或补丁提交消息 - 使用编辑指令git rebase -i
(发现主题?)。
以任何方式改变补丁(即其内容,描述或父母)的任何活动都将创建一个新的提交,其中包含该补丁的新提交ID。旧提交可能被丢弃并在它们被提升到稳定主分支之前被定期更换的事实是使它们成为“补丁队列”而不是分支的唯一因素,但这是项目约定而不是任何物理差异在构成提交的数据中。要git它们是相同的对象。
将补丁提升为“真正的”提交只是将补丁移动到队列的前面并将其合并到主分支中。将补丁移动到队列的前面后,它与基于主分支的正常提交相同,因此合并它只是快速转发主分支指针以指向补丁提交。
将此提交发布为“稳定”主修补程序是这样的行为:现在这是一个不会更改的提交,并且是项目的不可变历史记录的一部分。
答案 2 :(得分:9)
只需使用分支并定期将其重新绑定到您的上游分支。这比使用mq更容易管理和更安全(过去我丢失了数据)。
答案 3 :(得分:7)
Git本身并没有提供此功能。根据您的使用情况,您可能可以使用“git stash”和/或分支,但这将是非常基本的。如果人们使用git有更高级的补丁管理需求,他们似乎转向Quilt或StGit:请参阅http://git.or.cz/gitwiki/PatchManagement