Struggling with an ideal Git branching strategy for a simple whitelabel solution

Question

I am moving my source code into Git from TFVC land, and I figured it's time to clean up and do it properly - at the moment there is a lot of copy/pasting going on.

My project has a 'main' solution - which is seen as the Gold Standard if you will. However my project is adaptable to different businesses, with content differences between the two, and some contain esoteric business logic that differs from each other (in what I believe to be a relatively loosely coupled way).

I don't know the best strategy to maintain a 'master' build, and different releases.

Do I make one repository with several branches for each release, or do I split them up into different repositories (but then obviously I won't be able to merge new code, so this isn't ideal).

I have followed a 'Release Isolation' strategy in the past:

F1 ------
        |--MASTER----------------
F2 ------          |---v1.4     |---v2.0
                     |             |
                     |--HF1        |--E1

Sorry for the horrible visual, but Master is where my deployments would come from, F1/2 would be features, v1.4/v2.0 are releases we need to support, with HF1 being the hotfixes that are from supporting that release, and E1 being enhancements added to that release.

Any hotfixes would be merged back towards Master, and when Master was filled with enough new and tested features to go live, we would create a new release (v3.0).

The problem is, I don't know how this model could be adapted to my WhiteLabel

F1 ------
        |--MASTER(main client)----------------
F2 ------                     |---client2     |---client3
                              |               |
                              |----v1.0       |
                              | |--E1         |--v1.1
                              |----v2.0         |----HF1

I don't know if this is stable enough.

If I have a Feature that is going across all builds, I can start on the left side of Master, and push across to the new versions of each release and reconcile any merge issues then and there.

If I have a bug (i.e. HF1) then I would have to merge it across a LOT of branches (well, at least the supported releases and dev/master branches)

Is this ideal or am I going completely the wrong way?

score 1 · Accepted Answer · answered Jun 19 '17 at 17:31

I call it - the forked master strategy.

                            (The Times)
                          ----MASTER---
             WSJ-MASTER---|   |    |  |---FT-MASTER
              |       |       |    |        |     |
              |       |       |    |        |     |
              |   WSJ-RELEASE |    |        |     FT-RELEASE
           |---       |       |    |        |             |
           |        WSJ-HF1   |    |        FT-FR1        |---FT-HF1
  WSJ-FR1--|                  |    |                      |
           |       TIMES-BF1--|    |--TIMES-RELEASE       |---FT-HF2
  WSJ-BF1--|                  |               |             
                   TIMES-FR1--|               |--TIMES-HF1

In this hypothetical example of owning a software product sold to different newspapers, The Times is considered our core platform, and we produce slight variations (hence forked master).

We don't need 'release isolation' because we are supporting one version of the website only. On the left-sides of the 'masters', we have all new development (i.e. enhancements/bug-fixes/forks for large changes to codebase).

On the right side, we have a 'release' branch which is always in line with what is in production, so we can easily branch off it for hot-fixes.

Used it for the last few days (I appreciate that's a pathetic amount of time) and so far so good!

Struggling with an ideal Git branching strategy for a simple whitelabel solution

1 Answers1