I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI.<p>The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't seem to pass CI). The time between code being written and a bug being seen can be reduced to minutes and hours, making finding the root cause a breeze.<p>Just my preference, but very open to debate.
The advice here given to avoid using "master" branch for development, and advice to create non-default branch named "develop" (or variations thereof) is quite harmful.<p>If you must have a "release" branch or "stable" branch, ok, go for it, but leave the "master" for developing. Why? Strive to have sane defaults.<p>Frankly, the idea that somebody must check out some extra special branch after cloning repo in order to start properly developing, is not sane.
It is good exercise to actually learn this branching model and then use it in practice. You will soon realize that most projects will suddenly start taking unnecessary toll on you just because now you want to maintain multiple branches and it is a huge PITA.<p>Instead just follow this simple routine - stay as close to the master as possible. If a temporary diversion is needed, create a new branch (and maintain both master and the diversion for a while). Delete the diversion once the job is done.<p>If you are never able to delete the diversion, it is not your git branching model that failed, it is you and your code who failed. Diversions may be long term (and I hope you have the workforce to maintain that branch as well) but still finite time. How to prepare that diversion is a software engineering problem and not git's fault.
Do not use Git Flow for a web application deployed on your own infrastructure (SaaS, microservice, mobile backend, etc.). It will slow down development and make your software less reliable.<p>The entire purpose of Git Flow is saving up changes to release later, e.g., saving up for a weekly release event. Don't do that! Deploy your changes as soon as they are ready, if they aren't ready don't merge them into a shared branch. If you do Continues Delivery you don't need "hotfix" branches because every changes goes out as soon as it is ready, so you don't need any of the complexity of Git Flow.<p>By saving up changes for a release event it means more things are getting released at once. If there is a problem after deployment it will be harder to narrow down the cause. Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on, and expect someone to test and stabilize their changes before release. With trunk-based development (<a href="https://trunkbaseddevelopment.com/" rel="nofollow">https://trunkbaseddevelopment.com/</a>) or GitHub Flow (<a href="https://guides.github.com/introduction/flow/" rel="nofollow">https://guides.github.com/introduction/flow/</a>) developers take ownership of their code, and only merge to master after they have tested it. With a good deployment pipeline they can own their code all the way to production.<p>Git Flow also encourages humans to think about and make up version numbers, like 15.0.5. This is a pointless waste of brain power, web apps don't need version numbers. The artifact systems (packages, containers, etc.) may need something, but it can just be an incrementing number that no on thinks about.<p>Git Flow wastes so much time, and makes everything it touches so complex, all to enable the harmful behavior of saving up changes for later, and enabling the pointless use of version numbers.<p>Trunk-based development and Continues Delivery is the default way people develop, it is how you would work if you had a one person company with one customer. It also is how the biggest web companies in the world work. It scales from smallest to largest. Just use trunk-based development. Stay away from Git Flow.<p>Edit: Fixed spelling of incrementing.
For a moment I thought: Has someone figured out something better than git-flow? But no, it's the original git-flow article again.<p>It's good, but now exactly "news". Every git user should be aware of git-flow, even if you do have a better way of using git.
I've used the git-flow approach successfully with a small team working on a medical product (so, embedded software system) -- every feature branch had to be reviewed before being merged with `develop`, which was submitted to nightly, extensive functional tests (initially one-hour long, eventually kept as a nightly subset of the more than 24-hours complete QA run) before it could be approved as a new (monthly) release and be merged with `master`. Every new feature branch was automatically treated to quick continuous integration tests, and available for manually-triggered full functional tests (on the target devices).<p>This approach ensured that we had a full trace of development work, (signed) code reviews, and software changes -- compatible with FDA audits.<p>We also automated collection of code coverage data during functional tests, to inform analysis and revisions of the battery of functional tests.
GitLab has a good discussion on Git flow too. <a href="https://about.gitlab.com/2014/09/29/gitlab-flow/" rel="nofollow">https://about.gitlab.com/2014/09/29/gitlab-flow/</a>
This was very much valid before the docker workflows came to happen.<p>Now maintaining two mainline branches forces you to break "don't build a container per environment" cardinal rule. Trunk based development should be the go-to repository strategy for dockerized apps.