There will be times where your Pull Request will have merge conflicts and the pending rebase label. This means that your changes conflict with what is on the main OpenRCT2 repository, and the diff cannot be applied cleanly. This happens because someone changed the vicinity or the actual same code that you were tinkering with and now git doesn't know which version to keep. This might have been caused by two things:

1. Your fork is fairly old and the file has changed dramatically since then.
2. Your fork was synced, but some other Pull Request that altered the same file was merged before yours, and now it conflicts.

There are two ways of solving merge conflicts: the first is to always have your repository synced when you start something, but that won't always prevent it, so the second is solving the issue itself.

It is very simple to sync with the OpenRCT2 repository, as long as you never push things onto your forks develop branch. You should do it, ideally, every time you're about to start a new branch or when you need to solve merge conflicts. To do so:

1. git checkout develop
2. git pull upstream develop --rebase
3. git push

That's it, now your fork's develop is the same as OpenRCT2's develop.

Eventually, even if you try to keep the fork as synced as possible, you'll have merge conflicts, it happens. To solve them, you have to first sync your develop branch, as shown above, and then rebase your other branch onto the recently synced develop.

Note: We do want rebase and not merge, as the latter creates a messy and hard to review PR. GitHub tutorials and tools sadly encourage merge, so take care when acting.

To solve the merge conflicts:

1. Sync your develop branch, as shown above.
2. git checkout your-branch
3. git rebase develop: This will eventually print "merge conflict..." messages which will require you to open each file listed and solve the conflicts
4. git add -u: Once you are sure the conflicts pointed out have been solved. You can search the repository for <<<< to be sure.
5. git rebase --continue: To continue the rebase.
6. git push -f origin: Once the rebase is done and successful, push your rebased branch to GitHub.