git-flow for multiple staging / production environments

Question

I am trying to apply git-flow for a project with multiple websites that share a same code base.

I currently use many feature branches, one develop branch, one support branch, and MANY production branches: one for each site, since some config files are customized per site.

The git flow tool does not propose many master/production branches, but a single one. What can I do?

Answer 1

Frankly, this sounds like an application configuration problem -- not a git problem.

We've found ways in our systems to natively support 'overwrite' files -- where the system first looks for a custom file and falls back the default one.

If you can't make your application dynamically customizable at runtime I'd implement a build process that did the overwrites at deploy time.

Answer 2

solution 1) develop maven artifacts in subproject and upload them to a custom nexus. then every project of yours can import those artifacts

solution 2) adapt git-flow to your own needs. in our case for example, we have several release-branches and no develop branch. every branch is created from the master. this way we are very flexible and can create short and long-term releases on-the-fly, just by merging all features-branches into a release. this way you could also create special-releases for each of your environment

ps: if you use the git-flow scripts-bundle, then you have to forget about those and do it by yourself (is not so difficult)

Answer 3

My solution is the following:

• each environment has its own branch;
• I have a file (pom.xml, in my case. But this is not important) which contains last deployed version for that specific branch.

When I need to deploy, I run a script on my PC that:

• reads the current checked-out branch's name (the branch on which I want to deploy to);
• reads the last deployed version and increments it according to an input parameter (bug, fature,major..);
• creates a tag with {new version}-{environment},
• updates current version in pom.xml;
• pushes all (also tags).

On the server, I run a script that:

• pulls the corresponding branch;
• finds out the tag that describes that branch (git describe --tags);
• checks out that tag;
• stops, compiles, copies, starts.