在 Git 中管理项目变体的最佳实践中有一个类似的问题？但上下文不同，我怀疑答案也可能如此。
我有一个使用 Xcode 管理并使用 git 进行版本控制的 Cocoa 产品“First”。“第一”仍在发展，目前是第三版。
然后一位客户过来询问 First 的变体，称为 Second。从 First 到 Second 的更改会影响许多（但不是全部）文件。这些更改会影响源代码，但也会影响资源（图形元素、nib 文件、属性列表......）。
现在这两个产品还活着，并且共享许多通用文件。但是，某些更改（例如错误修复）可能适用于这两种产品。可能会为这两种产品添加新功能。
管理这种情况的最佳方法是什么：
- 使用 Xcode
- 用 git
我有两个想法，它们是相互排斥的：
想法 1：git 将“First”分支到“Second”，并将任何适用的更改从一个项目应用回另一个项目。这导致两个完全独立的 Xcode 目录和项目。
想法 2：在 Xcode 项目中添加一个名为“Second”的目标。现在同一个 Xcode 项目有两个目标，用于开发和构建这两个产品。但这使得在 git 中管理 First 和 Second 的发布变得困难（发布没有理由同步）。
想法 2 使并行开发过程变得非常容易。代码始终保持同步。可以通过编译时变量和单个源文件或通过不同的源文件来处理分歧。但是，它使版本管理更加模糊。
想法 1 可能更简洁，但是，管理两个项目之间的共同点的最佳实践是什么？您可以在两个 git 分支之间进行“部分合并”吗？依据是什么？还是必须手动处理？
可以将一些通用部分封装并提取到模块或库中，但并非总是如此。例如，我认为常见的文档图标不可能。此外，重构“First”以便以可构建的方式提取所有常见项目是一项我宁愿一次做一点的重大任务。
我意识到可能没有完美的解决方案。我正在寻找想法和建议。作为一个相对较新的 git 采用者，我也意识到这可能是一个 RTFM 问题。然后只需将我指向 FM 到 R。
非常感谢。