Git branching practice with two release targets

Question

I have a simple question about git branching practice :

Say there are master & develop branches. All feature development tasks are working on corresponding feature branches, targeting at develop branch. (feature branch is branched off from develop)

I have tasks for the release of app version 1.0.0 , in the meantime, I have also tasks for the future release of app version 1.1.0.

I know in general, tasks should targeting at develop branch, but I don't want to release 1.0.0 which contains feature for 1.1.0 , so, I can't have all tasks merging to develop branch.

The solution I could come up with is having a temporary branch (branch off from develop) for 1.1.0, tasks for 1.1.0 merged to that temporary branch. Wait until release candidate branch for 1.0.0 is created, then, merge that temporary branch to develop for future release 1.1.0.

Do you have a better practice then what I come up with?

Answer 1

I know in general, tasks should targeting at develop branch,

That is mainly true for the popular git-flow workflow. There is no "should" about it, and git itself has no opinion about how you use it.

git-flow works when you have just a single "next" release, if you pretty well know what goes into the next release, and if you usually do not wish to back out changes from your develop branch. For example, in my current main project, these three assumptions are wrong. So we do not use git-flow.

The solution I could come up with is having a temporary branch (branch off from develop)

Why branch off of develop, in the first place? You can use master (with the meaning of "current release") instead. If all your branches are sourced from master, and you get rid of develop, and you have ephemeral future-release-branches which are frequently re-built from scratch (reset to master, merge all relevant features into them) there is no problem targetting multiple future releases while still developing all new features in parallel. There is a workflow called branch-per-feature which is very great for this.

Answer 2

The answer to this question will vary by workflow (and that will vary by team preferences and project nature), so the question flirts with being opinion-based or over-broad... but I guess some general thoughts would be:

The easiest thing is to minimize the overlapping time during which features are being developed for multiple releases. From a priority-and-effort standpoint, this usually makes sense anyway.

For example the popular gitflow workflow more or less assumes that open feature branches are all (at least potentially) for the upcoming release. Once you close the feature set for version x, you create the version x release branch. Only release-related work and minor bugfixes should occur on the release branch (which eventually gets merged back to develop so that such fixes aren't lost). And it's when the feature x release branch is created, that any open features become "version x+1 features" and you open any new features that you already were withholding for the x+1 release.

(A related point: it is often useful to be flexible in what features go to what release, so that you can release when the time comes with whatever value is ready to go. This is somewhat related to agile thinking.)

But if you find that actively developing two versions is the way to go for your project, you'll need to do something different. I'd get away from the idea of a develop branch at all, because of the branch name juggling that would ensue.

So then release-development branches (e.g. dev-1.0.0) could replace develop. You'd create a release-development branch from the prior release-development branch, but thereafter you'd have to regularly incorporate changes from the previous release-development branch into the current release-development branch. Since this is a shared/long-lived branch, you wouldn't want to do that by rebase, which means periodic merge commits are likely what you'd need.

There are other ways, and like I said it wanders quickly into opinion territory once you get away from the documented-and-time-tested approaches.