Rebasing is a method to integrate changes from one branch into another. It’s essentially like “replaying” changes from your branch onto another branch. This is helpful when you want to ensure your changes are built upon the most recent commits of the branch you’re targeting.
Rebasing a pull request in GitHub allows you to update the entire commit history of a branch onto its base branch, while the base branch received new commits.
Mergify allows to rebase pull requests in two different ways:
Either by using the
rebasecommand which rebases the pull request immediately;
Either by using an automation rule that automatically triggers a rebase when a pull request meets conditions.
Rebasing a PR from GitHubSection titled Rebasing a PR from GitHub
To instantly rebase a pull request without leaving GitHub, use the Mergify rebase command by typing:
This command triggers a
git rebase operation and force-push the rebased
rebase command provided by Mergify has several advantages over the native
GitHub rebase feature:
Rebases are done using the
--autosquashoption. This mean commits starting with
squash!or other commands will be honored.
dismiss_reviewsaction is being used, it will not reset the reviews if the rebase is executed by Mergify.
It’s always available, whatever the repository configuration might be.
It can be restricted to certain users or teams.
Automatically Rebasing PRsSection titled Automatically Rebasing PRs
You might be tempted to rebase pull requests automatically when they are behind
their base branch, such as
action is a great candidate to help in such a case.
You can write an automation rule that does exactly this for you:
Note that this rebases the pull request as long as it has the label.
If you wanted to rebase only once, you would also need to remove the label once the rebase is done:
Rebasing Outdated Pull RequestsSection titled Rebasing Outdated Pull Requests
As rebasing a PR is likely to re-trigger your CI, rebasing your PR continuously could be time consuming for your CI system. Rather than doing it on every merge done in the base branch, you can rebase only when the PR is behind a number of commits. For example:
With this rule, as soon as the pull request is more than 10 commits behind the
main branch, Mergify automatically rebases the pull request which therefore
retriggers the CI. This is useful to make sure that you don’t merge pull
request that are too much out-of-date.
Rebasing Pull Requests Once a WeekSection titled Rebasing Pull Requests Once a Week
As stated above, rebasing too often your pull requests might not be great for your CI resource usage. Therefore, you could also use a strategy where rebase would only be done during a certain time frame, once a day.
With this rule, any pull request that is out-of-date between 8am and 9am PST during the week will be rebased.