维护遗留代码并开发新功能时，如何高效管理私有补丁集？

我太懂这种维护遗留代码的处境了——私有小改进（日志补充、性能小修复）没法走审批合入主分支，但没有这些改动又没法高效开发新功能，反复变基的工作流确实是个pita。下面分享两种可行的方案，重点讲你提到的Stacked Git（stg）的具体用法，完美匹配你想要的补丁流程。

一、Git原生补丁方案（轻量但不够灵活） #

如果不想引入新工具，Git自带的补丁功能就能满足基础需求：

• 生成补丁：切换到my分支，把私有改动生成补丁文件：

  # 生成最近N个提交的补丁（比如你有3个私有改动提交）
  git format-patch -3 --output-directory ~/my-patches
  

• 应用补丁：在新的feature分支上：

  git am ~/my-patches/*.patch
  

• 撤销补丁：如果要合并到development前需要去掉补丁，用：

  # 撤销最近应用的3个补丁
  git reset --hard HEAD~3
  

这种方案的缺点是补丁管理不够灵活，没法单独调整某个补丁的内容，也不能快速切换补丁的启用状态。

二、Stacked Git（stg）：专为补丁流设计的工具 #

stg本质是在Git之上提供了一层补丁管理，完美解决你需要的“随时应用/撤销补丁、在分支间迁移补丁”的需求。针对你的场景，具体操作步骤如下：

1. 先把my分支的私有改动拆成stg补丁 #

首先在你的my分支上初始化stg，并把现有提交拆成独立补丁：

git switch my
stg init
# 把最近的N个私有提交拆成stg补丁（假设你有3个私有改动提交）
stg uncommit -n 3
# 此时可以用stg list查看所有补丁，每个补丁对应一个逻辑改动（比如add-logs、fix-login-performance）

如果你的提交不是按逻辑拆分的，也可以用stg new逐个创建补丁，手动把改动分配到不同补丁里，这样后续管理更清晰。

2. 导出补丁到本地存储 #

把这些补丁导出到本地目录，方便在其他分支导入：

stg export -d ~/my-patches
# 每个补丁会被保存为单独的.patch文件，文件名包含补丁名称

3. 在新的feature分支导入补丁 #

当你基于development创建新的feature分支后，导入补丁：

git switch development
git checkout -B feature-new
stg init
# 从本地目录导入所有补丁
stg import -d ~/my-patches
# 用stg list确认补丁已导入，stg push --all可以一次性应用所有补丁
stg push --all

4. 日常开发的补丁流程（完全匹配你的期望） #

• 开发时：补丁已应用，你可以正常开发新功能，同时享受私有改进的便利
• 准备合并到development时：

  # 先把所有补丁弹出（撤销应用）
  stg pop --all
  # 此时分支状态和纯development一致，正常合并feature分支到development
  git switch development
  git merge feature-new
  

• 创建新feature分支时：

  git switch development
  git checkout -B feature-next
  stg init
  stg import -d ~/my-patches
  stg push --all
  # 继续开发，重复流程
  

5. 额外技巧：在开发中更新私有补丁 #

如果在feature开发时需要修改私有改进（比如新增更多日志）：

# 先切换到当前补丁对应的改动（比如add-logs）
stg goto add-logs
# 修改代码后，更新补丁
stg refresh
# 导出更新后的补丁到本地目录（覆盖旧文件）
stg export -d ~/my-patches --force

三、其他可选工具 #

• Quilt：老牌补丁管理工具，和stg类似，但命令体系和Git的集成度不如stg
• Git stash系列命令：你现在已经在用到，但stg比stash更适合长期维护多个独立补丁

总的来说，stg完全能解决你的痛点，把繁琐的变基流程替换成更直观的补丁应用/撤销操作，强烈推荐上手试试。

内容的提问来源于stack exchange，提问作者motobói