So I joined a team that's recently (within the last year) moved from TFS to GIT. The branching strategy is this. Dev -> Release -> Master. When Dev is ready, merge to Release. Build from Release and deploy to various environments. Once it reaches the first production environment, merge to Master so master is always a preserved state of production. If there's a hotfix needed, make the change in Dev, Cherry-pick to Release and once deployed to prod, cherry-pick to master. Never merge backwards from Master to Release or Release to Dev, always flow the code one direction.... If we do need to merge backwards, it's either another cherry-pick (if you can find it) or a huge merge with tons of conflicts.
Pros:
- Simple
Cons:
- Commit history is useless between branches as they won't match up.
- Changes accidentally made directly to Release or Master and no Dev, will never make it back to Dev until someone notices the bug again after it's over-written or a merge conflict alerts someone (not likely since this is a mostly blind merging and people will be trained to ignore merge conflicts.)
So, being this is a very TFS centralized way of doing things and I'm pushing for a two branch system. Dev and Master. When we're ready with a release, merge Master back to Dev to make sure everything is in sync, then Dev to Master tagging the commit for easy reference if needed. in the event of a hotfix, branch from master, make fixes as needed, deploy as needed and merge back to master. If needed in Dev, then merge Master back to dev, or wait for the next release.
Pros:
- Commits only get lost if someone deploys from HF branch and forgets to merge back to Release (I argue deploy to prod ONLY from Master to force the merge... but builds take a LONG time so that's a sticking point...)
- Commit History will match between branches so you KNOW things are in sync
- Merge conflicts should be greatly cut down and/or handled by the person making the change so they better know how to handle them.
Cons:
- More complex, especially if you're coming from TFS... I've been there before
- If multiple hotfixes are going on at the same time, this can get messy.
So, another developer on the team agrees that the Cherry-pick branching strategy has a few issues but argues it's simplicity should mean that changes not making it back to dev should almost never happen and commit history alone isn't worth the effort of the git strategy.
Problem is, I don't have a response to that. Fundamentally the idea of not being 100% positive the code going to prod is what you tested in dev irks me to no end... but I can see how others it might especially at higher risk of forgetting something in a Hotfix branch by not merging it back into Master. Also, I like Git, though I'm no expert, but the git branching strategy makes sense to me.... however, having made the transition from TFS to GIT myself years ago, I can see how complex things look and that there will be many mistakes before it becomes second nature to everyone.
My question is, are there more compelling reasons to use a get branching strategy? I've searched quite a bit for "Cherry Picking branching strategy" and other variants and haven't come up with anyone suggesting it, so I'm hoping I'm missing something major here.
