Is it a good practice to use branches to maintain different editions of the same software?

Question

We have a product that has a few different editions. The differences are minor: different strings here and there, very little additional logic in one, very little difference in logic in the other. When the software is being developed, most changes need to be added to each edition; however, there are a few that don't and a few that needs to differ. Is it a valid use of branches if I have release-editionA and release-editionB (..etc) branches? Are there any gotchas? Good practices?

Update: Thanks for the insight everyone, lots of good answers here. The general consensus seems to be that it is a bad idea to use branches for this purpose. For anyone wondering, my final solution to the problem is to externalize strings as configuration, and externalize the differing logic as plugins or scripts.

Answer 1

This depends on the magnitude of the change, but I wouldn't consider it good practice for the differences you described.

Generally, you want a Git branch to be something that will be merged in the future or stored read-only for reference. Git branches that co-exist indefinitely mean work for everyone: Changes need to be propagated and merged, conflicts resolved, all the fun. If nothing else, every developer has to remember to push changes to five repositories instead of one.

If you have small changes, the whole merging and branch-keeping effort seems overkill when compared to the problem. Use your preprocessor or build system to differentiate between versions. Does a simple #ifdef do the trick? Then don't solve problems with git, it's overkill.

Answer 2

That's not really what branches are for. Branches are supposed to be short to mid-term side paths to your line of development, not long-term parallel versions of the same code.

I'd put all the different versions into the same branch, with a subdirectories for the parts that are different between editions, and set up your build process (you have an automated build, right?) so that it can output either edition on demand (or all of them at once).

After all, you want to keep a "single source of truth"; with branches, you'll be duplicating some code, but not all, and certain merges would in fact break your setup.

Answer 3

One solution - as people have pointed out - is to configure the build system to support different editions.

I would also consider implementing it as feature toggles and use a configuration file. The less you have to build, the better.

Have a look at this site.

Answer 4

I would think that's an good idea provided you can't do it within one branch without clustering the code to much.
I would prefer to be able to keep it in one branch and use localized and configuration files, especially if you say the differences are minor.
Another way could be different builds, for example your build file packs different files for different customers but I can also see the build tool checking out different branches. As you use git I would say no real gotchas. One branching strategy could be to develop on different branches for different tasks, check in to the master branch and merge from master to editionX and Y.

Answer 5

This sounds more like a job for different build configurations. thiton’s answer goes into this direction but I would take it much farther than #ifdef:

Use different build targets to build different editions of the software. Targets may differ by

• the configuration they include,
• the object or source files they include, or
• the preprocessing of the source code.

This preprocessing may obviously include the classical C preprocessor but it could also entail using a custom preprocessor, a template engine to build custom views, …

This way, you avoid having to actively push every single change out to multiple branches, which violates DRY (of course that too can be automated but I don’t see the advantage).

Answer 6

I would use branches only for significant changes, otherwise you end up adding every little change to numerous branches, which is not fun at all to do and is very error prone, especially if you're working with more people.

Answer 7

If you are releasing them all as different products then having multiple branches is recommended. If not, then it's still recommended to use something like a trunk or a master branch.

Also, I think this would depend on the development process you have, particularly deployment. If you have a process that only permits one branch to be rolled out to production and branches are being treated as "incremental builds" meaning release B can't be rolled out to production unless release A was rolled out first, given that all changes of A are already in B, then having multiple branches is the way to go. This will work if you have teams scattered all over the globe and you usually have changes ordered by priority.

Answer 8

The solution with the three different branches (for production, development and features) works really well. Lets say you discover some bug in your production code then you can apply a patch to that then release it. Just make sure you don't do any feature additions to the production branch or any major changes to the production branch. You and your team will have to self-discipline to not add any major feature changes to your production branch. The production branch should just be for minor bug fixes that don't warranty a major change in your production code base.