4 ms·
If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that
by jgraham 6y ago
If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages:
* It's clear which states master has actually been in, without having to resort to squashing each merge into a single commit. This means that you know which commits actually passed CI and are therefore good rebase targets. People often claim that when merging multiple commits each commit should individually pass CI, but that's almost impossible to achieve in practice.
* Development can split single features into multiple commits for easier review and understanding later. This can be particuarly important if the changes depend on each other, but different people need to review different parts of the overall change. That's another thing that most tooling is really bad at.
* The history is basically linear. The merge commits are all empty, and there is one linear history for all the states of master (the first parent of each merge commit) and one linear history for all the individual commits (the second parent of each merge commit and only parent of each non-merge commit).
Of course this approach isn't well supported by mainstream tooling (e.g. GitHub) and probably requires a custom bot to do all the rebase-and-merge operations. It is pretty well supported by git itself, however.
- ufo 6y agoDoes anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.
- tele_ski 6y agoI always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?
- ufo 6y agoDo you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.
- tele_ski 6y ago"Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.
- divbzero 6y agoYou can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired. [1]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuring-commit-rebasing-for-pull-requests https://docs.github.com/en/free-pro-team@latest/github/admin... [2]: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/requiring-a-linear-commit-history https://docs.github.com/en/free-pro-team@latest/github/admin...
- ufo 6y agoThanks, but I don't think that is quite what I want. What I mean by "cactus" history is that the feature branches have a linear history that starts at the tip of the master branch but when we merge them back into master we still use a merge commit. Looks like this: o-o-o o-o-o o-o / \ / \ / \ o-------o-------o-----o We like doing that because, as the grandparent poster said, it clearly delineates the point where each PR was merged. AFAIK, the Gihub option to require a linear history assumes that you would want to flatten all the commits without any merge commits at all: o-o-o--o-o-o--o-o
- karyon 6y agoI don't know a way to enforce this, but what may help is knowing that by default, you can push into the PR branch even if it is from someone else's fork: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork https://docs.github.com/en/free-pro-team@latest/github/colla...