rebasing, then submitting a pull request afterward, which branch do I push?

Question

I've used git for a while now but have always shied away from rebasing, simply because I didn't understand it well enough and have been burned by it.

Now I'm trying again, and in reading the documentation I see that I'm supposed to checkout my feature branch and run git rebase target to apply my changes to the target branch.

Then, apparently, I'm supposed to checkout the target branch and run git merge feature_branch from there? To accomplish a fast-forward merge? So rebasing is actually a two-step process, so to speak?

I can do that, but I'm wondering when I open a pull request on github, what do I do then? I'm used to generating a PR from my branch, which if approved is then merged into the target branch. But now, if I rebase on the target, should I push and open a PR against that same branch? Is this standard operating procedure when using rebase?

Just seems a little different than what I'm used to and wanted to make sure I follow correctly.

Answer 1

But now, if I rebase on the target, should I push and open a PR against that same branch? Is this standard operating procedure when using rebase?

Yep, you rebase your branch on target and open a pull request for your branch.

So rebasing is actually a two-step process, so to speak?

No, rebasing is the process of getting your branch to "stem" from the tip of the target rather than from its actual location.

The second step you refer to is how to get the changes merged into master, which is a separate thing. Rebasing allows you to do fast-forward merge, but in the context of open source projects on Github the reason people will ask you to rebase is simply to keep the history clean. They will still force a merge commit but history will be more readable than if the branch was created off a commit way down the history.