在Best practice for managing project variants in Git?有一个类似的问题，但背景不同，我怀疑答案可能也是如此。
我有一个使用Xcode管理的Cocoa产品“First”，并使用git进行版本控制。 “First”仍在不断发展，目前正处于第三版。
然后客户来询问First的变体，称为Second。从First到Second的更改会影响许多文件，但不会影响所有文件。这些更改会影响源代码，但也会影响资源（图形元素，nib文件，属性列表......）。
现在这两个产品还活着并共享了许多常见文件。但是，某些更改（如错误修复）可能适用于这两种产品。可能会在两种产品中添加新功能。
管理此类情景的最佳方式是什么：
我有两个相互排斥的想法：
创意1：将git branch“First”改为“Second”，并将任何适用的更改从一个项目应用回另一个项目。这导致两个完全独立的Xcode目录和项目。
创意2：将名为“Second”的目标添加到Xcode项目中。现在，相同的Xcode项目有两个目标，用于开发和构建这两个产品。但这使得很难在git中管理First和Second的版本（版本没有理由同步）。
Idea 2使并行开发过程变得非常简单。代码始终保持同步。可以通过编译时变量和单个源文件或通过不同的源文件来处理分歧。它使版本管理更加模糊。
想法1可能更清晰，但那么，管理两个项目之间共同点的最佳做法是什么？你能在两个git分支之间进行“部分合并”吗？在什么基础上？或者必须手动处理？有可能将一些公共部分封装并提取到模块或库中，但并非总是如此。例如，我认为普通文档图标不可能。同时重构“First”以便以可构建的方式提取所有常见项目是一项重大任务，我宁愿一次做一些。
我意识到可能没有一个完美的解决方案。我正在寻找想法和建议。 作为一个相对较新的git采用者，我也意识到这可能是一个RTFM问题。然后简单地指向FM到R。
非常感谢。
答案 0 :(得分：0)
我的偏好是idea2。我目前这样做是为主应用程序编写插件，然后是在集群的所有节点上运行的客户端应用程序。插件和客户端共享90％的相同代码，因此可以非常轻松地维护和调试正在进行的操作的位置和方式。