The approach that has worked best for me is pretty simple.
Master should always be in a deployable state.
Any commit that lands on master must include unit tests that demonstrate that it works (or at least doesn't break anything).
Incomplete features that will take more than a week or so to develop should be merged to master early protected by feature flags. This avoids long running branches.
I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history.
People who prefer to review smaller commits can do so in the pull request - it's only the finished item that gets squashed into a larger commit.
Master should always be in a deployable state.
Any commit that lands on master must include unit tests that demonstrate that it works (or at least doesn't break anything).
Incomplete features that will take more than a week or so to develop should be merged to master early protected by feature flags. This avoids long running branches.
I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history.
People who prefer to review smaller commits can do so in the pull request - it's only the finished item that gets squashed into a larger commit.