1

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?

ReynierPM
  • 17,594
  • 53
  • 193
  • 363
  • Do you maintain several concurrent versions of your software, such as a "v1.0" and a "v1.1"? If not, I would recommend not using git-flow at all. It's only useful when you need to maintain more than one version, such as continuing to support old versions of your software with security patches. – user229044 Jun 10 '19 at 13:59
  • @meagar I do not mantain versions I will take note on your suggestion – ReynierPM Jun 10 '19 at 14:06

1 Answers1

0

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

  • One master branch as normal
  • One develop branch from master as normal
  • web4_master is a branch from master
  • web4_develop is a branch from web4_master

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.

Vlad274
  • 6,514
  • 2
  • 32
  • 44