git rebase origin/develop vs git rebase develop

Your local branch develop tracks origin/develop and they might not always have the same commits in them.

$ cat ~/.git/config[remote "origin"]    url = git@something.com/repo.git    fetch = +refs/heads/*:refs/remotes/origin/*

This means we have a "remote" (a repository living somewhere else) arbitrarily named "origin".

Your local develop branch is tracking the branch from that remote repository, and there's a local reference to that data called origin/develop. For the most part, we consider these two things to always contain the same commits. However, you need to explicitly update your local develop branch to get the latest data from origin. This is mostly commonly done with a pull:

$ git status    on branch develop$ git pull    ...pulls latest changes from origin

However, a git pull actually does two steps, a fetch and a merge. The first step it does under the hood is fetch all the latest commits from origin, which you can do with

git fetch origin

This will update the branch origin/develop, but not your local branch develop.

The newest commits are hidden "behind the scenes" in your local .git directory, which you can reference from the branch named "origin/develop".

After a fetch, to actually make your local branch origin, you would have to do git merge origin/develop. This technically isn't a merge, it will be a "fast forward," meaning git is smart enough to make your local origin branch match origin/develop without actually merging anything. For this reason and others, merges freak me out in git.

So if you rebase off of develop, there's a chance it will be out of date (older) than origin/develop.

I personally do this workflow before rebasing:

git fetch --allgit rebase origin/branchname

This means that I can pull all data down without having to think too much about what branch I'm on, and rebase off the latest code from the remote repository. Later, on the develop branch, a simple git pull will make sure you're up to date.

If develop points to the same commit as origin/develop then the two commands are exactly the same. I would tend to use origin/develop in case I had forgotten to update my local develop (assuming this branch is eventually going to be pushed to origin/develop).

As I wrote in my other (long) answer to your previous question Why is "rebase --onto ABC" different than "rebase ABC"?, both of these commands turn off --fork-point mode, so—provided that both develop and origin/develop resolve to the same commit hash, as they do in your question premise—the two commands will do the same thing.

Omitting the <upstream> argument turns --fork-point on by default, and the reflog for the branch's configured upstream may have a lot of data in it. In this case, they may act quite differently. By adding an explicit --no-fork-point, you can prevent git merge-base --fork-point from dropping upstream-removed commits.