I'd like to check what best practices are avail out there. I have the following requirements:

  1. I have a repo which is used for development (master and develop branches). I would like to keep track of alpha/beta/release candidates and release build. I am considering to create branches for alpha/beta/rc/rel and then when I will merge push develop to alpha and then alpha to beta etc etc. But in this case, the master branch is left without any useful usage and the develop will only work in the pre-alpha phase. After an alpha version, I have to branch from alpha branch.

  2. I want to keep track in a VCS the whole package that ships to the customers. So, I am considering to create a separate repo with release builds and all the additional material (docs, license, etc.etc).

  3. The application is cross-platform which means that for each of the above I need at least three other branches (win32, win64 and macos)

All in all, it looks very complicated process. So, what is a common approach here?


  • Which approach works best for your specific workflow? Commented Jun 18, 2016 at 15:32
  • @Robert This is a new project so I am very open to adjust my workflow. My concern is that the above plan is very complicated Commented Jun 18, 2016 at 15:35
  • @charlotte: Thanks for the tips. Does alpha/beta/release depend on the team size? Anyway, In my question, I don't know how to handle the full release package. Say you need documentation, etc. I was thinking to create a separate repo for this Commented Jun 20, 2016 at 18:33
  • @Charlotte: I see. Thanks for the tips. If you wanted to send a version to testers (beta testers) outside the organisation, would you send a debug version according to your setup? Commented Jun 21, 2016 at 16:35
  • I am a fan of this branching model. Maybe you can also find some inspiration there?
    – hoffmale
    Commented Jul 16, 2016 at 16:13

1 Answer 1

  1. I favor working on 'main' or 'trunk' and not branch for (ahead of) releases, but branch after release when needing to provide a fix for some older version out in the wild, I absolutely try to minimize the amount of different version I have to maintain. When you are at beta will you still support the alpha version of your software? I think alpha/beta/rc/release is sequential, not parallel, it does not need branches, it just expresses the readiness/stability of your 'trunk'.

  2. Distributions I have created by a build server, I associate the distribution with the build number and version control revision. This way I can create a 'release' branch later on if needed for a hot-fix/patch. I rarely ever do this, since I try to fix forward on the latest version (try to keep all installations at the most current version).

  3. I have no real experience to speak of here but I assume most code will actually be the same, using compiler directives as suggested by some of the comments sounds like a better strategy. You can also select platform specific implementations using your dependency injection configuration. If you branch by platform you might risk having your branches stray so far apart that any attempt to merge between them becomes a major pain. I recommend finding abstractions to seam out the platform differences.

I prefer to keep branching to a minimal, in my experience, it leads to late integration, it discourages refactoring (you will run into un-mergable or very complex merges). I keep unstable/unfinished features out of production by using feature toggles.

  • Just read your comment. You're right about the sequential nature of the releases. Thanks for the points Commented Sep 8, 2016 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.