-1

From my understanding,

git pull --rebase origin master

is equivalent to

git fetch origin
git rebase origin/master

So if we simply just do git rebase origin/master instead of git pull --rebase origin master, is the only difference that any new commits from the remote master branch won't make it to our local branch? Or are there edge cases that I need to be aware of?

Hypothetically, if all we want to do is rebase and no longer work with the current local branch, is there ever a need to incorporate the git fetch origin step?

roulette01
  • 1,984
  • 2
  • 13
  • 26
  • 2
    "Not work with the current local branch"? But if you rebase, you do keep your local branch. If you want to abandon it, you don't have to rebase it at all, just switch to a different branch. Please clarify. – j6t Dec 11 '21 at 14:21
  • 1
    yeah, your request doesn't compute. If you won't use the local branch, why are you bothering to rebase/update it? Or do you, by "local branch", actually mean local `master` and you want to abandon the local commits on it? – Inigo Dec 11 '21 at 14:46
  • `origin/master` is how your Git repository remembers *their* repository's `master`. It will get out of date as their repository acquires new commits, so you must refresh it from time to time with `git fetch origin`: your Git software, running on your repository, calls up their Git software, directing it to their repository. Your Git gets a list of their Git's branch names and commit hash IDs. Your Git obtains from their Git any new commits that they have that you don't, and then your Git updates your memory of their branches. – torek Dec 11 '21 at 23:10
  • You choose when and how often to refresh. If you like, you can delete the name `master` locally (though you'll need to be on some other branch name locally, or in detached HEAD mode locally, to do this) so that you're not tempted to use your name `master` any more. Some people like that, some don't; it's a matter of taste / opinion. – torek Dec 11 '21 at 23:11
  • @torek I'm not a new git user, but I've always kind of blindly used it in the past, and this post has made me realize that my understanding is really lacking... I think I understanding the remote branch `master` and what `origin/master` is. I previously had thought that `origin/master` is the same as the local branched named `master` (the one that shows up when I do `git branch`). It seems that's not correct. Is origin/master something that I can visually inspect? – roulette01 Dec 12 '21 at 01:30
  • 1
    @roulette01: `origin/master` is a name. Your Git repository has two databases: one contains Git *objects* (found by hash ID) and one contains *names* (branch names, tag names, etc). Each name holds just one hash ID. Run `git for-each-ref` (not a very user friendly command, but try it out) and you'll see (almost) every name, with its full spelling and corresponding hash ID, plus the object's type. `origin/master` is just shorthand for `refs/remotes/origin/master`: the full spelling of this name. – torek Dec 12 '21 at 02:01
  • *Branch* names (`refs/heads/*`) are constrained to hold only commit hash IDs. Remote-tracking names (`refs/remotes/*`) are your Git's memory of some other repository's branch names; since they're branch names in the other repo, they must also hold commit hash IDs (not tag hash IDs or anything else weird). So you, or Git, can resolve the name to the hash ID, and now you have access to a commit. This commit will be there in your Git's objects-database. `git show ` will show it, the way `git show` shows any commit. – torek Dec 12 '21 at 02:03
  • To see the hash ID in any one particular name, rather than all of them at once like `git for-each-ref`, use `git rev-parse`: `git rev-parse master` turns `master` into a commit hash ID, and `git rev-parse origin/master` turns `origin/master` into a commit hash ID. (We know they're commit hash IDs by the rules I just mentioned.) – torek Dec 12 '21 at 02:04
  • Note that the objects—commits, tags, and other internal Git objects—have *unique* hash IDs. When we say *unique*, we mean it: not just unique to your Git repository, but unique in *every* Git repository, even if they don't have your commit (yet). That's why the hash IDs are so big and ugly: every commit, and every other Git object, ever created, must get a unique one. That way, if you bump two repositories into each other, they can just look at the IDs and tell if they have the same commits, or not. – torek Dec 12 '21 at 02:06
  • So, if their Git with their repo says *my master is `a123456`* and you have an `a123456`, you (your Git) knows you and they *share* this one commit. If you don't have `a123456` at all, you can get it from them, and now you and they share this one commit. Either way your Git can now set your `origin/master` to hold `a123456`. – torek Dec 12 '21 at 02:08
  • This all raises a really fundamental question: [What exactly do we mean by branch?](https://stackoverflow.com/questions/25068543/what-exactly-do-we-mean-by-branch) Sometimes we mean a branch name, sometimes we mean a remote-tracking name, and sometimes—pretty often, I think—we mean "some subset of my commits". – torek Dec 12 '21 at 02:09

1 Answers1

3

Stack Overflow is not really suited to "should" or "need" questions. What you do is something you must decide. What we can do is clarify for you what your code means. Let's say this is the initial situation:

A -- B -- C -- D <-- master on the remote

A -- B -- C <-- origin/master on your computer
 \
  X -- Y <-- your local branch

If you are on your local branch and you now rebase onto origin/master, you'll get this:

A -- B -- C -- D <-- master on the remote

A -- B -- C <-- origin/master on your computer
           \
            X' -- Y' <-- your local branch

If you had said git fetch and then rebase onto origin/master, you'll get this:

A -- B -- C -- D <-- master on the remote

A -- B -- C -- D <-- origin/master on your computer
                \
                 X' -- Y' <-- your local branch

Which is better? Only you know. It depends on why you are rebasing.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Ah I think I confused myself earlier, hence why my question didn't mask sense. In your example is `origin/master` the same as the local branch called `master`? – roulette01 Dec 11 '21 at 15:41
  • No, it's the same as the remote-tracking branch called `origin/master`. A remote tracking branch can never be "the same as" a local branch. One is a remote tracking branch, the other is a local branch. – matt Dec 11 '21 at 15:52
  • 1
    If you were already _on_ a local `master` that comes from the remote-tracking branch `origin/master`, what reason would you have to rebase it onto `origin/master`? If you didn't fetch first, absolutely nothing would happen, so what would be the point of that? – matt Dec 11 '21 at 15:54
  • In terms of "types" of branches, there are 3 kinds in 1) local 2)remote tracking 3) remote, right? When you rebase, are you rebasing onto 2 or 3? I think that's maybe where I'm getting lost in the terminology/thought process. – roulette01 Dec 11 '21 at 16:10
  • 1
    You are working locally, not on the remote. You don't "have" the remote branches; they are on the remote, the remote has them. You have local branches and remote-tracking branches. You can rebase onto either of those. A branch is a branch. (Actually, you don't rebase onto a branch; you rebase onto a commit. You can rebase onto any commit you have, no matter how you happen to have it.) – matt Dec 11 '21 at 16:21