CODEWITHSUNDEEP
gitgit-rebase
Polymerase
Polymerase

Reputation: 6781

git rebase origin/develop vs git rebase develop

Let's assume the current branch is MyFeatureX. And the local develop branch is up-to-date with origin. Would the two statements below be equivalent? What is the recommended syntax?

git rebase origin/develop 
git rebase develop

Please note: This is not the same question as git rebase origin vs.git rebase origin/master

Upvotes: 25

Views: 73670

Answers (3)

Andy Ray
Andy Ray

Reputation: 32066

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

$ cat ~/.git/config

[remote "origin"]
    url = [email protected]/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 --all
git 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.

Upvotes: 33

torek
torek

Reputation: 488183

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.

Upvotes: 1

Penguin Brian
Penguin Brian

Reputation: 2131

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).

Upvotes: 4

Related Questions