Never touch the master branch...

Unless you're pushing working and documented code.

@Berkmann18 Not even then, always branch it and pull from the branch

Wise words my friend

@wellitonpaiva had to learn it the hard way

@corjaantje this is why I hate GitHubs PR system. People think that by using a PR they're not touching master. You are. It creates a culture of fear around deploying software. Deployment shouldn't be scary. It should be boring and something that you don't even really think about because of how easy it is to do.

My recommendation: don't commit directly to master. Merge into master often, anytime you have code working.

First rule of software development:
Never touch the master branch.

Second rule of software development:
NEVER TOUCH THE MASTER BRANCH

It's a poster that hangs on my wall.

@jimmeh I need a poster like this!!!

If you are like me and you don't understand how use Git correctly, use **Git Flow**!

@davejlong Exactly.

Well if you practice continues deployment then the idea of branching is bad. My opinion is always commit to master so you don't delay the integration, but!! you should have all the quality gateways in place like unit testing, integration testing, cucumber, some form of code inspection and all automated in the build. The idea: fail hard and fail fast so you can fix and deploy.

My philosophy
4 branches
Local
Development
Staging
Master

Only work in local. Development only gets merged into from local. Staging from development. Master from staging.