54

我刚开始使用 Git 和 Mercurial 来熟悉 Git。

我在 Mercurial 中广泛使用 mq 扩展来管理本地补丁，我正在寻找一个 Git 等价物。

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

谢谢，

4

4 回答 4

32

查看Git Wiki 上接口、前端和工具页面的“补丁管理接口层”部分。列出了两个补丁管理接口，大致相当于 Mercurials 'mq'扩展：

  • StGIT（Stacked Git），两者中较老的一个，用 Python 编写，使用两个快照来表示补丁
  • Guilt（以前称为“gq”），编写为一系列 bash 脚本、系列文件和补丁（每个文件一个）存储为纯文本文件。
  • pg (Patchy Git) 已弃用，不再维护。

但是，如果您不需要更高级的用法，则可以改用“ git rebase --interactive ”来重新排序、压缩和拆分补丁。为了根据当前版本的上游管理您的分支，“git rebase”通常就足够了。

于 2009-06-04T20:18:36.470 回答
32

免责声明：我不是 hg 用户，所以我读过 hg 但没有太多使用它的第一手经验。

git 提供了几个非常强大和灵活的工具来管理“补丁队列”风格的分支，因此对于许多基本（甚至一些非常复杂的）用例，本机 git 足够强大。

通常，大多数项目都会保留一个中央稳定的主分支，它只会获得新的提交并且永远不会“回滚”，因此主分支中的提交是固定的。

在此之上，维护者（或开发人员）可以维护一个或多个基于稳定分支的正在进行的补丁（即提交）的流动分支。

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

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

将补丁队列复制到旧的维护分支上 - 使用git branch和git rebase，

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

squashing patch -git rebase -i与 squash 指令一起使用

更改补丁或补丁提交消息 -git rebase -i与编辑指令一起使用（发现主题？）。

任何以任何方式更改补丁的活动（即其内容、描述或父系）都将为该补丁创建一个具有新提交 ID 的新提交。旧的提交在升级到稳定的 master 分支之前可能会被定期丢弃和替换，这是使它们成为“补丁队列”而不是分支的唯一原因，但这是项目约定而不是任何物理差异在构成提交的数据中。对于 git，它们是相同的对象。

要将补丁提升为“真正的”提交，只需将补丁移动到队列的前面并将其合并到主分支中。将patch移到队列的最前面后，就和基于master分支的普通commit一样，所以合并它只是将master分支指针快进指向patch commit。

将此提交发布为“稳定”主补丁的行为表明：这是一个不会更改的提交，并且是项目不可变历史的一部分。

于 2009-06-04T20:33:42.837 回答
9

只需使用一个分支并定期根据您的上游分支对其进行变基。这比使用 mq（我过去丢失数据）更容易管理和更安全。

于 2009-06-04T20:18:38.390 回答
7

Git 本身并没有真正提供此功能。根据您的用途，您可能可以使用“git stash”和/或分支，但这将是非常基本的。如果人们对 git 有更高级的补丁管理需求，他们似乎会转向 Quilt 或 StGit：参见http://git.or.cz/gitwiki/PatchManagement

于 2009-06-04T20:05:55.793 回答