xcode - 用于同一产品不断发展的变体的最佳 git 和 Xcode 结构

Question

Best practice for managing project variants in Git?有类似的问题但上下文不同，我怀疑答案也可能是这样。

我有一个 Cocoa 产品“First”，使用 Xcode 进行管理，并使用 git 进行版本控制。 “First”仍在不断发展，目前已是第三个版本。

然后，一位顾客过来询问 First 的一个变体，称为 Second。从 First 到 Second 的更改会影响许多文件，但不是全部文件。这些更改会影响源代码，还会影响资源(图形元素、nib 文件、属性列表...)。

现在这两个产品已经上线并共享许多通用文件。但是，一些更改(例如错误修复)可能适用于这两种产品。可能这两种产品都会添加新功能。

管理这种情况的最佳方法是什么:

• 使用 Xcode
• 使用 git

我有两个相互排斥的想法:

想法 1:git 将“First”分支到“Second”，并将任何适用的更改从一个项目应用回另一个项目。这导致两个完全独立的 Xcode 目录和项目。

想法 2:将名为“Second”的目标添加到 Xcode 项目中。现在，同一个 Xcode 项目有两个目标，用于开发和构建这两种产品。但这使得在 git 中管理 First 和 Second 的版本变得困难(版本没有理由同步)。

Idea 2 使并行开发过程变得非常简单。代码始终保持同步。可以通过编译时变量和单个源文件或通过不同的源文件来处理分歧。但它使版本管理变得更加模糊。

想法 1 也许更清晰，但是管理两个项目之间的共同点的最佳实践是什么？你能在两个 git 分支之间进行“部分 merge ”吗？依据什么？或者必须手动处理？

也许可以将一些公共(public)部分封装并提取到模块或库中，但并非总是如此。例如，我认为对于常见的文档图标来说这是不可能的。另外，重构“First”以便以可构建的方式提取所有常见项目是一项重大任务，我宁愿一次做一点。

我意识到可能没有完美的解决方案。我正在寻找想法和建议。作为一个相对较新的 git 采用者，我也意识到这可能是一个 RTFM 问题。然后只需将我指向 FM 到 R。

Answer 1

我的偏好是idea2。目前，我这样做是为主应用程序编写插件的一种方式，然后是在集群的所有节点上运行的客户端应用程序。插件和客户端共享 90% 的相同代码，因此这使得维护和调试发生的位置/方式变得非常容易。