A Really $h!t Branching Policy
Here’s an example of a really $h!t branching policy:
Look how hateful it is!! I imagine this is the kind of conversation that leads to this sort of branching policy:
“Right, let’s just work on main and then take a release branch when we’re nearly ready to release”
“Waaaaait a second there… that sounds too easy. A better idea would be to have a branch for every environment, maybe one for each developer as well, and we should merge only at the most inconvenient time, and when we’ve merged to the production branch we should make a build and deploy it straight to Live, safe in the knowledge that the huge merge we just did went perfectly and couldn’t possibly have resulted in any integration issues”
“You see! Its complexity is beautiful”
Branching is boring. Merging is dull and risky. Don’t have more branches than you need. Work on main, take a branch at the latest possible time, release from there and merge daily. Don’t start conversations about branching with girls you’re trying to impress. Don’t talk about branches as if they have personalities, that’s just weird. Use a source control system that maintains branch history. Floss regularly. Stretch after exercise.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)