1

I'm trying to figure out whether I would be able to utilize a modified gitflow Git workflow, and I'm struggling with it (not sure if it's relevant, but planning to use Atlassian Stash):

We currently use CVS, and have multiple on-going large-scale projects. We do new project production releases every month or so, but each project might be in development between 1 wk to 6 months. We also do weekly maintenance releases. There can be up to around a dozen or so projects in active development. We also need ability to run nightly regression testing on each project branch as well as maintenance. Given the per-file nature of CVS, we split manual merges between half a dozen developers when large-scale merges are needed.

So far my best idea is to use modified gitflow where we'll have the following branches:

master: what's currently in production

develop: development branch for next production release, project branches that will be released with next release will be merged here, as well as small features not release to larger projects (both new features and production bug-fixes)

project/project_name: Project development/integration/testing branches. This is branched off develop and is merged back to develop when project dev is complete. Some project/project_name branches can be branched off existing project/project_name branches if they require functionality of a project-in-development.

feature/ticket_no: feature branch, branched off from develop for smaller non-project features. Branched off from project/project_name for larger projects.

release/release_number: release branches, branched off from develop branch as we decide it's time to cut the release. Merged to master.

bugfix/ticket_no: bugfix branches, branched off from release/release_number branches for bugs found by QA. Merged back to release/release_number and develop.

hostix/ticket_no: hotfix for urgent production issues. branched off from master. Merged into master, develop, and release branches.

Does this sound workable, or am I shooting myself in the foot here due to huge merge complexity that will arise? Any suggestions for alternative approach?

Releasing more often is not a possibility to do limited ability to get approved downtime for a release.

Pavel Chernikov
  • 2,186
  • 1
  • 20
  • 37

1 Answers1

0

The workflow you described sounds very similar to what I have seen at the last two shops where I have worked. The great thing about Git is that it doesn't cost very much to create a new branch. So while there might be a hefty penalty for creating so many branches in CVS, in Git you will find it possible to create your entire workflow in a matter of minutes.

You mentioned Atlassian Stash, and it merits making mention that this is referring to the repository you plan on using. The repository is the (usually remote) location where your team will store the commits from all branches. Git is Git, whether you use GitHub, Stash, BitBucket, or any other repository, so the functionality you have won't change based on the repo. However, the repo usually adds tools to make managing the remote branches easier. As an enterprise level repo, Stash stands out in this regard, and it should be able to handle your use cases.

That being said, you won't necessarily have fewer merge conflicts when using Git. And it is not typical to have multiple developers resolving a single merge conflict in Git.

And as one side note, Git doesn't handle binary files very well out of the box. So if your current CVS repo is laden with binaries, then you will want to review all version control tools before adopting Git.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360