Getting your PR ready for Mautic 3

By Dennis A. · PUBLISHED April 02, 2020 · UPDATED April 03, 2020

Getting your PR ready for Mautic 3

If you’ve provided a Pull Request against the Mautic repository on GitHub, thank you!

As you might have seen, Mautic’s Core Team has been busy working on Mautic 3, which introduces major changes under the hood. At the same time, a large number (200+) of Pull Requests were created against Mautic’s staging branch (2.x).

When Mautic 3 is released (expected soon), we will only be providing bug fixes against the 2.x branch due to it being very far behind on Mautic 3. At the same time, we don’t want your Pull Request to go un-merged. In the end, contributions like yours are what makes Mautic better every day! 🚀

Therefore, we’d like to ask you to check the following (before you start, please add WIP to the title of your PR so that everyone knows you’re doing something with it):

Type of PR



Is the bug still present in Mautic 3?

  • Yes: rebase your PR against the 3.x branch and we’ll check if it can still be merged in Mautic 2
  • No: please comment on your PR: “This PR only applies to Mautic 2.x”. We’ll make sure it gets tested then.

New feature

Is the feature still missing in Mautic 3?

Enhancement (to existing functionality)

Is the enhancement still missing in Mautic 3?

How do I rebase my PR against Mautic 3?

For this example, you would check out the my-pr branch, and then rebase it onto the 3.x branch as follows:

$ git checkout my-pr 

$ git rebase 3.x

First, rewinding head to replay your work on top of it...

Applying: added staged command

This operation works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.

As this process works through commit-by-commit, if your PR has 10 commits, it will rebase each commit separately.

If there is a merge conflict during this process, it will stop and ask you to resolve them.

Once you do, you have to

git add /the/file/with/resolved/conflict.php

and then continue with the rebase with

git rebase --continue

It may happen there will be conflicts in more than one commits, and even in several files in one commit.

At this point, you can go back to the master branch and do a fast-forward merge.

$ git checkout 3.x

$ git merge my-branch

While rebasing is a good process to start with, larger PRs may become somewhat unmanageable, so you can consider using git merge instead, however rebasing gives a much a cleaner git history - merge will create a new commit, whereas rebase alters existing commits.

For further documentation on rebasing please check the Git Documentation. If you need any help please don't hesitate to ask the Product Team for support via the Slack channel.

How long will it take for my (updated) PR to be processed?

Once you have completed the process, the product team will review your rebased PR within two weeks and will provide any feedback as appropriate. 

They will also determine which release to aim for.

Please keep in mind that there is a large backlog of PRs at the moment, but we try to respond as fast as we can.

Want to help us with this project? Consider getting involved with the Product Team - to get started, please join our Slack channel!