So I have a branch called feature 1 as part of a pull request to merge into dev, where I've done some work.
There's another branch called feature 2 that's part of a different pull request where the page I'm working on was refactored.
What's the best way to get feature 2 into the feature 1 branch? Should I be branching off feature 2, merging feature 2 into the feature 1 branch, or rebasing feature 1 onto feature 2?
Let's assume your branch situation looks something like this:
A---B feature2
/
o---o---o dev
\
C---D---E feature1
What you want is to rebase your work in feature1 on top of feature2:
A---B feature2
/
o---o---o dev
\
A'---B'---C'---D'---E' feature1
To do that, you can run:
git rebase feature2 feature1
Which basically says "checkout feature1 and rebase it on top of feature2". Of course, be prepared to resolve the conflict that will inevitably appear in the page that both you and the author of feature2 modified.
You may wonder why rebase? Well, because it produces a clear history regardless of which branch gets merged first into dev.
For example, let's consider the scenario where feature2 is merged before feature1:
A---B feature2
/ \
o---o---o---o dev
\
A'---B'---C'---D'---E' feature1
In that case, once you rebase feature1 on top of dev, Git will detect that the changes introduced by commits A and B are already in dev, so it will remove them from feature1:
A---B feature2
/ \
o---o---o---o dev
\
C'---D'---E' feature1
What about if feature1 is rebased before feature2:
A---B feature2
/
o---o---o-----------------------o dev
\ /
A'---B'---C'---D'---E' feature1
The same thing applies here. Once you rebase feature2 on top of dev, A and B are going to be removed from feature1 because their changes are already present in dev:
o---o---o---------------------o dev, feature2
\ /
A'---B'---C---D---E feature1
Of course, if new commits were added in feature2 after you rebased your feature1 on top of it, those commits will still be kept:
F---G---H feature2
/
o---o---o---------------------o dev
\ /
A'---B'---C---D---E feature1
First of all, pull requests are not a part of the git protocol. Pull requests are only something implemented by git hosting services such as GitHub to provide a review function before a merge. If your questions is actually related to any feature related to pull requests then you also have to tell us what hosting service you are using. However, in my understanding, your question can be boiled down to what the difference between merge and rebase is, and both those features are a part of the git protocol.
The current state of a branch can be thought of the sum of all commits previous to the commit that branch points to. And as with mathematical sums, the end result does not depend on the order you sum items in, and that is one way to think of the only difference (kind of) between merges and rebases. So, if you only care about the end result of the current version of the branch, then stop reading and do whatever you think is easiest.
The difference between a rebase and a pull request is how the history will look. A rebase of feature-1 to feature-2 simple creates a new branch from feature-2 and copy all commits on feature-1 to the new branch, then deletes the feature-1 branch and rename the new branch feature-1. So it is no longer the same commits. They are identical, but they are no longer the same and they have different hashes. In general, this creates a cleaner history, but it is in one way a less true history as it looks as if the branch feature-1 was always created of feature-2 which it wasn't.
A merge from feature-2 to feature-1 will create the same end result of the current version of feature-1 branch, but the history will show that branch feature-1 was first created from main/master, had commits made to it, and then feature-2 was merged into it before both feature-1 and feature-2 were merged back into the default branch.
So, the end result will be the same, it is just a matter of what story you want the repository history to tell. And to many people that rarely matters.