Git model: branches for features based on master

Question

I organize my Git projects based on the article A successful Git branching model. The problem is that I don't know how to handle the following case:

• develop: working on a major app redesign (taking ~6 months)
• master: current production version

However, because we access paid customizations (from enterprise customers), sometimes a customer requests, for example, a new report to be added.

That's technically not a hotfix, but a feature. And features should not branch off from master or a release branch. Even more, if the feature is big enough, it could be a complete difference release. So, while master has v1 and develop has v2, where do I work for features that go to v1.1, v1.2, and so on?

What I currently do is, branch a feature from master and merge back to master and develop. Is there any workflow model that's more appropriate/organized?

Answer 1

A few considerations stand out to me.

Consider having your major redesign in a branch off of develop rather than in develop. Effectively, what is in develop should represent your next release. If you have an extended test or hardening period, you can create a temporary release branch from develop, test and harden that, and then ensure that is in both master and develop - in this case, I tend to merge the release branch into master and then master into develop.

Try to do the best you can do not have things hanging out in very long running branches. If you're doing a major redesign, there may be some things that do need to hang out by themselves until the end. I'm not suggesting that this is easy, but trying to get things integrated and deployed sooner is better for getting feedback and iterating. Whenever you make changes to an upstream branch (such as develop), you should pull these into the long running branch as well, and frequently. At some point, your longer running branch for the redesign can get merged into develop and become targeting the next release.

• Thomas Owens: @DocBrown I added that - it was definitely my intention to include that, but yeah. You want to (1) get work into develop and deployed as fast as possible and (2) when you can't deploy the work, you need to get any deployed work into the long running branch as frequently as possible to ensure it doesn't introduce defects or cause conflicts.
• Diego Jancic: Makes sense. I shouldn't have had my redesign in develop in first place. Thanks!
• Diego Jancic: BTW, we are publishing often the develop version in a beta environment. However, because it's for the academic industry, we cannot publish major changes during the semester.