1

Git-flow explains the following process for release branches -

  1. Release branch should be forked from develop branch
  2. Release branch should merged back into master branch, and a tag created from master branch.

My question is why is why should release branches be forked from develop and not master? Is there any benefit from doing so? I can instead

  1. Merge my develop into master
  2. Fork a release from master and then tag the master...

How will that affect the version management?

Utkarsh S
  • 13
  • 3
  • Maybe the assumption is that there could be some long fixes or other work going into `master` which you would not want to appear in `develop`. – Tim Biegeleisen May 17 '19 at 13:29
  • But the purpose of master is to be a "replica of a production ready stable code", as per GitFlow. so there should not be any fixes going on in master ideally, isn't it? – Utkarsh S May 22 '19 at 06:34
  • take a look at this answer [Alexey Andrushkevich answer](https://stackoverflow.com/a/39903624/9673980) or for more details : [minas's anwser](https://stackoverflow.com/a/20755706/9673980) – Bryan Neugebauer Oct 08 '19 at 08:33

1 Answers1

0

You almost answered your question in one of your comments:
the purpose of master is to be a replica of a production ready stable code

Let me elaborate on that:
(1) That statement is correct. master is production-ready. According to git-flow every commit (being a merge from a release or hotfix branch) leads to a new release.
(2) If you merge develop directly onto master you might end up with instabilities. That's what we create a release branch for. We use the latest version of develop but test them, make some bug fixes, adjust configurations etc.
Only when everything is fine we actually merge onto master and therefore deploy to our users.

A final - but very important - note here:
git-flow is just one of many ways to organise your code. It's not a this is the one and only solution for everyone and everything. It's just a suggestions, a framework. Adjust it to your needs or use a completely different framework / idea if it does not work for you. I rarely used git-flow in the past 15 years exactly the way it's documented. We always made some adjustments.
One of them btw being very closely related to your question: We would deploy from release and only if that deployment works and reached our clients (Apple's review process, I tell you!) we would merge to master and tag that release.

Dominic Frei
  • 327
  • 1
  • 5