At work we use Gitlab. The feature to only allow fast-forward merges to master is awesome.
The result is a linear history, that is much easier to bisect.
It also encourages developers to make small commits, since they are easier to rebase.
The result is a linear history, that is much easier to bisect.
It also encourages developers to make small commits, since they are easier to rebase.
https://github.com/isaacs/github/issues/1017
I really, really like semi-linear branching/merging. I.e. always rebase-merging, but with a merge commit.
Reasons, in comparison to Github's "rebase merge" which doesn't produce a merge commit:
1. It makes it clear which commits were part of one PR
2. It makes it clear who did the merge
3. It's okay to not have every commit build. but the one being merged will.
4. Still pretty bisectable. You'll narrow things down at least to the PR that caused an issue, and from there it's usually quite simple.
5. Looks very tidy in gitk & Co
The main page of a repository configuration in GitHub let's you enable/disable:
- Allow merge commits
- Allow squash merging
- Allow rebase merging
for PRs.
And under branch protection there is a "Require linear history" option.