主要观点：

• 叉维护（保持本地更改与原始项目的最新更新同步）容易变混乱，作者曾有相关经历，现分享步骤供其他开发者参考。
• 叉维护话题复杂，本文建议虽不一定适用于所有开发者，但希望对某些人有帮助。
• 建议开发者熟悉 git 概念，本文分为开发/工作流最佳实践和变基指南两部分。

关键信息：

• 日常开发技巧：使用原子提交（每个提交只描述一个更新，避免一个提交包含多个不相关更改）、识别修复和非修复提交、避免邪恶合并（合并提交不应引入更改）、尽早经常变基、将更改回推至上游、与上游保持良好关系。
• 变基指南：先整理 git 历史（通过 rebase 命令去除合并提交，得到线性历史）、最小化下游更改（ squash 下游提交，减少噪声和下次变基的负担）、将可向上游提交的更改放在开头（便于后续操作）、有效变基（可能遇到冲突，可部分保存变基进度）。
• 避免将复杂叉作为上游项目，可引入插件系统以减少维护问题。

重要细节：

• 原子提交的好处：有助于日常开发（如更易代码审查、更干净历史等），变基时能节省时间，避免因一个提交包含多个不相关更改导致的冲突。
• 识别修复提交的方法：可使用前缀或标签标识，方便后续查找和处理。
• 变基过程中的操作：如使用git rebase --interactive命令进行 squash 操作，可能需要逐步进行；移动可向上游提交的更改至开头；部分保存变基进度可通过创建分支实现，后续可继续 cherry-pick 剩余提交。
• 插件系统的作用：允许下游开发者在不修改上游代码的情况下扩展项目，如著名项目 Wordpress、VSCode 等都有插件系统，作者所在项目 Headlamp 也以此为重点。