Your master branch really should be your master branch. A branch that represents the most up to date working version you have, that everybody works in relation

Your master branch really should be your master branch. A branch that represents the most up to date working version you have, that everybody works in relation to. Only working, tested code should make it into master. Code reviews and automated tests are great tools for this, but ultimately, it's up to the individual developers to not be sloppy. Avoid long-lived branches and big merges. If you've got big features that take a while to complete, break them into smaller things you can deploy sooner or use feature toggles. Don't leave it too long between deployments. Small, frequent updates are far easier to manage and far less risky. A dozen deployments a day are better than a dozen a year. Everybody should stay up to date with master. Rebase on top of master before merging instead of having awkward merge commits that only obfuscate history. If you have people working on features that take multiple commits to implement, use feature branches. These should be rebased onto master and cleaned up before merging into master. If you combine all of the above, you're heading down a path similar to GitLab Flow or GitHub Flow, so strongly consider using one of those instead of coming up with your own from scratch. Don't use Git Flow. It overcomplicates things and offers zero benefits over the alternatives. As far as I can see, it's only popular because a lot of inexperienced Git users were feeling like they were adrift without a workflow, and a blog post with a snappy title came along at just the right time to catch their attention. If your team don't have good VCS habits, you need to do something about this. Small, frequent commits that do one thing and one thing only, good log messages, push and pull frequently, etc. If you can't describe the change briefly, you are doing too much in one commit. There's lots of best practices articles for Git that have been written – read them. Also read Pro Git, which is free on the Git website.