Kent Rancourt
1 min readMar 12, 2019

--

I agree that long-running feature branches represent an eventual merge conflict nightmare and should be avoided at all costs, but I don’t feel as if the case which most frequently prompts me, personally, to use a feature branch was covered here. I’d love to know your thoughts…

Suppose that the reason for the existence of the feature branch is experimentation, by which I do not mean an experimental feature, but rather an experimental implementation, in the truest sense — literally: “I’m not sure this approach is even viable, but I intend to find out.” Suppose that in support of this, you’re forced to incur architecturally significant changes — which is perhaps the reason for your hesitance over the approach to begin with. It’s plausible that you will wish to _atomically_ accept or reject this set of changes — preferring that the architectural changes not be adopted unnecessarily if you cannot make the rest of it work.

Do you have recommendations for how to accommodate this scenario?

--

--

Kent Rancourt
Kent Rancourt

Written by Kent Rancourt

Kent is a founding engineer at Akuity, working primarily with Kubernetes, Argo CD, and other open source projects.

No responses yet