使用分支维护同一软件的不同版本是否是一个好习惯？

我们的产品有几个不同的版本。区别是微小的：这里和那里的字符串不同，一个字符串中几乎没有其他逻辑，另一个字符串中几乎没有逻辑差异。开发软件时，大多数更改都需要添加到每个版本中。但是，有一些不需要，有一些需要有所不同。如果我有release-editionA和release-editionB（..etc）分支，是否可以有效使用分支？有陷阱吗？好的做法？

更新：感谢大家的见解，在这里有很多好的答案。普遍的共识似乎是为此目的使用分支是一个坏主意。对于任何想知道的人，我对该问题的最终解决方案是将字符串外部化为配置，并将不同的逻辑外部化为插件或脚本。

这取决于更改的幅度，但是对于您描述的差异，我认为这不是好的做法。

通常，您希望Git分支成为将来将被合并或只读存储以供参考的东西。无限期共存的Git分支对每个人都意味着工作：需要传播和合并更改，解决冲突以及所有乐趣。如果没有其他要求，每个开发人员都必须记住将更改推送到五个存储库而不是一个。

如果您进行小的更改，则与问题相比，整个合并和分支机构维护工作似乎是过大的。使用预处理器或构建系统来区分版本。一个简单#ifdef的窍门吗？然后不要用git解决问题，这太过分了。

那不是分支真正的目的。分支应该是开发线的中短期路径，而不是同一代码的长期并行版本。

我将所有不同版本放入同一个分支，并为各个版本之间不同的部分提供了一个子目录，并设置了构建过程（您拥有自动构建，对吗？），以便它可以按需输出任何一个版本（或一次全部）。

毕竟，您想保留“单一事实来源”；使用分支，您将复制一些代码，但不是全部，某些合并实际上会破坏您的设置。

正如人们指出的那样，一种解决方案是配置构建系统以支持不同的版本。

我还考虑将其实现为功能切换并使用配置文件。建造的次数越少越好。

看看这个网站。

我认为这是一个好主意，如果您不能在一个分支中做到这一点而又不将代码聚类到太多的话。
我希望能够将其保留在一个分支中，并使用本地化和配置文件，尤其是如果您说差异很小的话。
另一种方法可能是不同的构建，例如您的构建文件为不同的客户打包了不同的文件，但我还可以看到构建工具签出了不同的分支。当您使用git时，我会说没有真正的陷阱。一种分支策略可能是在不同的分支上开发不同的任务，签入master分支，然后从master合并到editionX和Y。

这听起来更像是针对不同构建配置的工作。thiton的答案朝这个方向发展，但我想做的比#ifdef：

使用不同的构建目标来构建软件的不同版本。目标可能会有所不同

• 他们包括的配置，
• 它们包含的对象或源文件，或者
• 源代码的预处理。

显然，这种预处理可能包括传统的C预处理器，但也可能需要使用自定义预处理器，模板引擎来构建自定义视图，…

这样，您可以避免将每个更改主动推送到多个分支，这违反了DRY（当然也可以自动执行，但我看不出优点）。

我只将分支用于重大更改，否则最终会将每个小的更改添加到众多分支中，这一点都不有趣，而且很容易出错，尤其是在与更多人一起工作时。

如果将它们作为不同的产品发布，则建议有多个分支。如果没有，那么仍然建议使用诸如干线或主分支之类的东西。

另外，我认为这取决于您的开发过程，尤其是部署。如果您有一个流程仅允许将一个分支推出到生产中，并且分支被视为“增量构建”，则意味着除非先发布了发布A，否则除非您先发布了发布A，否则发布B才能被发布到生产中。 A已经在B中了，那么走多个分支就是路要走。如果您的团队遍布全球，并且通常按优先级排列更改，则此方法将起作用。

具有三个不同分支（用于生产，开发和功能）的解决方案非常有效。假设您在生产代码中发现了一些错误，然后可以对其应用补丁，然后发布它。只要确保您没有对生产分支进行任何功能添加或对生产分支进行任何重大更改即可。您和您的团队将必须自律，不要在生产分支中添加任何主要功能更改。生产分支仅用于较小的错误修复，这些错误不能保证生产代码库有重大更改。