Git – Tag and/or branch strategies for environments when using git

First of all, since your specifications are rather unclear, I'm not sure how much of this really applies. But I'll give it a shot...

If your project has one single release cycle, you only need one repository. If your three teams need to release new version independently, it gets a lot messier. But for that I'd need more specific input. At the moment, it sounds to me like you need to stabilize your API, develop the library and manage your back-end development. If that's part of one project, go ahead and use one repository.

As for the branching, I'd recommend to always have one branch that simply represents the latest released and working version. This branch will probably mostly have merge commits. I like the idea of release branches independent of development branches as a release manager could then easily review everything (after feature freeze if you want so), scratch the last few itches, set the version properly, and merge into your production branch. (You could even bind hooks or deployment strategies to that merge in order to automatically push release onto your build system or something).

As I said above, I'd recommend having one release cycle within one repository. If you can have that, only one production branch will be necessary. If the teams really need to release new versions of the same project independently, it feels like there's something wrong with the project management. But that's again without knowing much about the team and project in general.

A style that I like much is the git flow as described by Atlassian. It suggests having one master (production) and one development branch. On development the actual work happens but, that usually splits up into feature branches. What I like is that a development manager (someone with deep technical insight) can manage the development branch. They decide whether to merge new features or not. At some point they will tell a project/release manager that the team's done and that project/release manager can then (together with the development manager) work out the last few glitches on a release branch before it'll be merged into master (and back into development, of course). It's just an interesting separation of concerns that developers are so keen on regarding different aspects of the very same projects. :)

Hope this helps a bit.

Hmm, well I have a .net example which might be technology agnostic.

I'll just do a quick summary.

• git repo per component with gitflow branching strategy

• all commits to develop trigger a team city build

• teamcity build amends the version with manual major minor + the build number in AssemblyInfo.cs ie 1.1.hotfix.build

• teamcity triggers nuget packaging using the same version number for nuget published libraries

• octopus deploys finished build to qa for manual testing (assuming all tests pass)

• if everything is good, manually deploy version to production via octopus.

Now this does mean you get A LOT of versioned packages floating about. We did experiment with use of the -prerelease flag but this required a further manual move package from prelease to 'normal' step and a requirement to rebuild components which depended on them.

The key thing is to version every build uniquely via some central process.

Then you are in the situation of 'hmm what versions do i want' rather than 'omg, what version have i got??'

Edit: re comments.

Just to underline that key thing really. Decide what branch constitutes completed software and version ALL commits to it. only deploy versioned software from this branch.

My view though is that you need to address your branching strategy.

• don't version feature (or any dev) branches.
• do version master
• only use packages from master