3

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?

Improve this question
0

1 Answer 1

Reset to default
6

What am I missing?

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

Improve this answer
16
  • 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, 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
    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
    Jan 20, 2020 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, 2020 at 16:27
  • 1
    @einpoklum: Well, that's what's makes it public.
    – Filip Milovanović
    Jan 20, 2020 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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