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?


What am I missing?

It breaks the golden rule of rebasing: Never rebase a public branch.

  • 1
    But 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 Jan 20 '20 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 Jan 20 '20 at 16:21
  • According to the flow article I linked to, there is a (single) develop branch; and many feature branches. – einpoklum Jan 20 '20 at 16:24
  • 1
    @einpoklum per copy of the repository. alice/develop and bob/develop and origin/develop might be in different states – Caleth Jan 20 '20 at 16:27
  • 1
    @einpoklum: Well, that's what's makes it public. – Filip Milovanović Jan 20 '20 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.