3 ms·
You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.
by mkesper 8y ago
You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.
- scrollaway 8y agoYup, that's what I'm arguing in favour of. I systematically disable merge commits on every repo I manage. I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.
- gdfasfklshg4 8y ago> I systematically disable merge commits on every repo I manage. Do you have buy in from other team members for this? Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?
- scrollaway 8y agoThere is no develop, master is continuously deployed. Users can create feature branches and PR them but there is just no merge commit, they are pulled in fast-forward. In projects where I need stable releases, I create stable/1.2.x type branches off of master at a point in time. I cherry-pick commits onto it after the first release if there are subsequent ones. You can see this in action here: https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/master https://github.com/dj-stripe/dj-stripe/commits/stable/1.2 https://github.com/dj-stripe/dj-stripe/commits/stable/1.2
- u801e 8y agoThough fast forward merge commits (where the referenced tree is the same as referenced by the second parent) can be useful because they provide a way for you to group related commits for a feature together (git log merge_commit^..merge_commit^2). There are features that require more than a single commit to implement.