Source control - branching strategies

Started by
10 comments, last by Alex Melbourne 11 years, 3 months ago

I used something similar before hand but my house mate showed me a technique he found called git-flow. It's amazingly helpful and I now use it for all my projects.

It's really just an idea but it's got a tool that apparently is being considered for merging into the mainline of Git.

Advertisement

Well, since the idea is apparently to move away from exclusive locking, ClearCase is clearly out. Also for a million other reasons that could make me rant for hours. After a few years of CC as work, people can't wait to migrate to just about anything that isn't a user-hating excuse to sell expensive trainings. Any tool that lets you remove a view without even warning you about remaining checkouts (after which only admin intervention will allow anybody to continue working) is clearly aimed at securing the jobs of CC admins.

Another thing that turned out to be extremely annoying is Visual Studio integration. Accidentally type in a file -> reserved checkout "behind your back". Point is: too much (or too automated) integration isn't always a good thing.

We're going to move to git for now, using the same strategy as described by Telastyn. Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).

f@dzhttp://festini.device-zero.de
Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).

You've basically just described git-flow. Tag your branches with prefixes so people know what is expected on that branch. Make use of 'hotfix/branch-name' for fixes that need to be done then have them merged to master.

This topic is closed to new replies.

Advertisement