In the git flow workflow, it is recommended to create branches for releases, and when the release-specific work is done, merge the result into the master and development branch.
I understand why we would merge a release branch into the master branch, rather than rebase master on the tip of the release branch: We don't want people to have history conflicts with master.
But I don't understand why it's recommended to merge the release branch into develop, rather than rebase develop off of master, at the commit merging the release branch into master. That seems more "natural" to me, and simpler to do.
What am I missing?
asked Jan 20, 2020 at 15:01
1 Answer 1
What am I missing?
It breaks the golden rule of rebasing: Never rebase a public branch.
answered Jan 20, 2020 at 16:01
-
1But it's the "development" branch... it's not a problem if its history changes. There's no commitment to its usability or stability. Although, ok, my beef is with their philosophy, not with your answer.einpoklum– einpoklum01/20/2020 16:19:06Commented Jan 20, 2020 at 16:19
-
1@einpoklum It's not the develop branch. it's a develop branch, even if it's
origin/develop. Unless you are the sole developer, at which point it doesn't really matter if you use a "standard" approach or not.Caleth– Caleth01/20/2020 16:21:43Commented Jan 20, 2020 at 16:21 -
According to the flow article I linked to, there is a (single) develop branch; and many feature branches.einpoklum– einpoklum01/20/2020 16:24:50Commented Jan 20, 2020 at 16:24
-
1@einpoklum per copy of the repository.
alice/developandbob/developandorigin/developmight be in different statesCaleth– Caleth01/20/2020 16:27:09Commented Jan 20, 2020 at 16:27 -
1@einpoklum: Well, that's what's makes it public.Filip Milovanović– Filip Milovanović01/20/2020 19:40:40Commented Jan 20, 2020 at 19:40