Why does git branch workflow merge into the production branch

Question

I am wondering why every git workflow merge develop into the production branch.

Is there any reason why we cannot just leave the old production branches and create new ones from develop (in case we have only those two "special" branches). What is in there what need to be merged. Anyway every hotfix should be put into develop aswell. I googled and read many blogs about this but no one mentions anything about it.

We are moving to GIT from CVS and wondering what is a good way to use branching.

• gnat: Possible duplicate of Is git-flow in the spirit of git?
• Bysmyyr: I found example what I mean: Release branches with GitLab flow docs.gitlab.com/ee/workflow/gitlab_flow.html#introduction

Answer 1

Well, because git-flow defines it this way. There is really no other explanation that is not already written up in the definition of gitflow...

If you don't like that definition, you can just opt to not do it...

After all, you should think about what fits best to the way you develop your code. For some, git-flow is the way to go, because they need the fine-grained control over the code base.

For others, git-flow is total overkill and impose too much management overhead to be viable.

git does not tell you how you should use it. It provides you with simple yet powerful tools to create whatever workflow you need.

• U. Windl: I also think (as done in the example) it's most important to design some (branching) concept and then communicate that concept to every developer involved. Having some concept is more important than having the "right" concept. While you can do mostly anything you'd like in git, only some discipline will avoid chaos that may be hard to fix later. Some related question would be "When to remove branches that were merged elsewhere?"