Java 应用程序重新命名-何时应采用分支策略？

注意：如果有必要，我们使用的是git（因此分支和合并很容易），这是一个Android应用程序（Java-因此条件编译并不真正适用）

与此问题类似，但如果您的软件的不同版本之间存在的不仅仅是UI差异，该怎么办？例如，如果不应将整个功能或子系统编译成一个重新品牌（例如，它包含一家公司的知识产权代码，其他公司不应使用该代码），该怎么办

在这种情况下，是否应该为每个重新品牌创建单独的分支？如果是这样，主/主分支有什么用处，因为它只会成为代码存储，而不会编译成任何有用的应用程序（奇怪）？但没有一个主/主分支意味着必须仔细挑选（单独选择）提交以跨品牌合并，这似乎是一个糟糕的方法

---

或者有没有其他不涉及分支的方法来解决这个问题

对于真正敏感的信息/代码问题，分支机构不会解决：
您需要：

• 将敏感代码库隔离到自己的git repo中
• 对于某些项目，请将其作为参考
• 在其他不应该看到该代码的项目中根本不要引用它

---

这样做的目的是为了确保没有任何敏感信息会被错误地从一个回购协议推送到另一个回购协议。

根据您问题中提供的信息，我建议不要使用分支机构

除非合并，否则分支机构将转移。因此，在所有应用程序中提供错误修复 分支将需要大量的挑选，或者至少需要非常小心的提交/合并处理

如何将特定于客户的代码放入应用程序加载的库中

赞成者：

• 只有特定于客户的代码才会被复制
• 泛型代码不会无缘无故地分叉
• 通用代码是根据通用接口编码的
• 特定于客户的应用程序部件仅装运给相应的客户

反对：

• 需要对通用接口进行仔细的设计和生命周期管理
• 用于查找和加载特定于客户的库的附加代码。（在Java或Android的构建过程中不太难）

---

如果客户需要/有权访问存储库，我完全同意。如果没有，我看不到对不同子模块的要求，只要构建过程只选择当前客户的LIB，而不包括其他客户的LIB。@Black way对我来说太冒险了。如果回购协议不存在，你肯定构建过程不会陷入混乱。@VonC我同意你们两人的观点-在这两个答案中很难做出选择，它们都是非常好的方法。最后，我们使用了一个单独的repo，但没有使用子模块，相反，正如Black所建议的，我们将为构建/部署过程留下一些工作。谢谢你们两位。