NRE Labs Community

MP1 Branching Strategy

I’ve been thinking for a while about how best to integrate work done as part of MP1 with the rest of the codebase. The work being done in MP1 is fairly incompatible with the existing architecture, and we’ll have to start ripping out huge swaths of code before it’s done. If that work is merged to master immediately when finished, we’ll have committed ourselves to finishing MP1 in its entirety (or close) before we’re able to even do a platform release.

Rather, I’m inclined to keep master entirely focused on improvements on the current architecture only, so that releases can continue normally, and we can get improvements/bugfixes into production in parallel.

I’ll come up with a nice visual later, but basically I’m proposing a branch like mp1-dev or something like that, and all PRs pertaining to MP1 will be merged there. While master chugs along the current way, I’ll take care of ensuring commits are merged back up into mp1-dev so that it has the relevant fixes as well, helping to prevent merge conflicts at the end of MP1.

Eventually, when we’re ready, we’ll merge mp1-dev back into master. This will be a very significant set of changes that will be landing on master at this point, so we’ll want to make sure we’re ready to make the mental switch to the new architecture, and drive towards a new release. That new release may very well be 1.0.

All that said, we will want to keep activity in master limited to only a bare minimum - things that really need to be improved or fixed before MP1 is done. Even though we’re allowing that kind of work to continue, it really doesn’t make a lot of sense to think about giant improvements or big undertakings until MP1 is in place.

I agree. We should commit all major changes related to MP1 on mp1-dev until we have an implementation that has all the major MP1 changes integrated into the existing implementation

Would https://nvie.com/posts/a-successful-git-branching-model/ provide guidance ?