Living on the Edge - Automated Merging (Part 2)
Continued from Living on the Edge - Automated Merging Part 1.
The risk of semantic merge problems (discussed in Part 1) is real, but there are considerable benefits to factor in when evaluating whether automated merging is right for your organization. The main benefit is ensuring fast propagation of changes. Automated merging helps ensure that once-fixed bugs never rear their ugly heads again. Besides, semantic merge problems occur even without automating merges, if the merge problem is missed by the human whose job it is to catch them. So while automated merging might increase the risk of having more semantic merge problems, it can also decrease other types merge problems, including the dreaded "repeat offender" bug.
The risk of semantic merge problems can be reduced by automating merges only along pathways most likely to produce a good result. For example, you might automate merges from a mostly stable release branch used (almost) exclusively for bug fixes back to MAIN.
Automerge - Fast Bugfix Propagation
Unlike branches for active new development, where all sorts of seemingly random change may occur, changes in bugfix-only release branches are more focused. They usually involve smaller chunks of changed text. Such changes are more likely to be amendable to successful automated merging.
Disclaimer: I am NOT recommending that everyone go out and automate your merges. There are risks. If your code is controlling the coolant rods for nuclear reactors, I'd prefer you don't do this -- especially not if I live near you.
As to the benefits, I offer some anecdotal evidence from those who embrace this aggressive merge strategy. Semantic merge problems do happen, and they cause all sorts of pain when they do. But actual occurrences are rare, and balanced against the benefit of virtually guaranteed fresh codelines, with changes never left behind, it is an acceptable risk to some.
To be continued ... Continued in Living on the Edge - Automated Merging Part 3.