Hi, Vote 1. Require a pull request before merging: +1
Vote 2. Require conversation resolution before merging: +1 Vote 3. Require linear history (Prevent merge commits from being pushed to code branches. Only "Squash" and similar allowed): -0.9 I really like a linear history, but I see some problems when enforcing it always: - when using rebase (in the Github frontend) the commit signatures get lost - sometimes I create two (or more) distinct commits for one pull request (e.g. adjusting the code style in one file vs. making the actual change for the bug/feature) - I want to keep them separate in the history - when you split a file (or class) in two separate ones (and want to keep the line history for both) git checkout -b split git mv BigClass.cs SmallerClass.cs git commit -m "duplicated file“ git checkout HEAD~ BigClass.cs git checkout - git merge --no-ff split -> when you squash the feature branch into master the line history will be gone I think we should use squash or rebase whenever it is possible, but leave it to the reviewer for special circumstances. Vote 4. Require status checks to pass before merging: +1 Vote 5. Require at least one positive review before merging: +1 Regards. Jan
