gitbranchgit-flowbranching-strategy

git flow with two master branches, is it possible?

I am working in a project with a weird branching scheme. Let's say this is a shared project repository that holds a few websites (just an example below):

from the sites above web1, web2, web3 shares the same functionality, web4 shares the same as the other plus a few changes. The previous team ended building a master branch for web1, web2, web3 and a web4_master for web4. Here is an example in how the branching looks like:

λ git branch
* web4_master
  master
  develop

I would like to use git-flow here as I do for the rest of the projects with a normal branching scheme (meaning only one master) but in this case I have to main master branches and sometimes code goes to master or to web4_master or both. Is there any way to handle this by using git-flow? Or do I have to be tied to the old way meaning merging changes to wherever they go manually?

Solution

  • Since web4 includes all changes for the other sites, I would structure the repo as follows:

    If a feature is for all sites, then the work is done in a feature branch from develop like "normal" git-flow. Eventually, this will be ready for release and merged into master.

    If a feature is just for web4, then the work is done in a feature branch from web4_develop, and eventually merged into web4_master.

    Essentially, there are two git-flows happening - one for all sites, and one for web4 specific things.

    The final piece:

    During the release process for all sites (or whenever makes the most sense for you), web4 needs to get the latest released changes.

    1. Rebase web4_master on to master. Likely there will be conflicts here, so resolve them as needed
    2. Rebase web4_develop on to web4_master. This will NOT be a standard rebase and will need to make use of the--onto` flag to avoid duplicating commits. See this for a detailed explanation
    3. Repeat step 2 for any web4 in-progress feature branches on to web4_develop.

    Essentially, this is treating the web4 tree as a long running feature branch from master.

    I would not recommend this if there are a significant changes from the "all sites" features, or if the changes are very widespread, since the conflict resolution will get to be annoying.

    In that instance, I would recommend the solution you had of manually merging changes to two root branches.

    It is also possible that this approach makes sense / is easier using a merge strategy, but that's not my preference for something like this.