How to solve the problem that git checkout & lt; branch-name & gt; `brings me an outdated commit?


I did git clone some 12 days ago, and then since then, I have updated or added a branch in that repo foo from upstream (where my repo was forked from GitHub).

But in that old directory, I could not even change to that branch at first.

And then, I did

git fetch --all
git checkout -b some-branch-name   # the  -b  is important or else it
                                   #   thinks some-branch-name is a filename

and can switch to that branch. But when I git log, I am seeing the most recent commit that was 12 days ago.

How do I make it current? If I git clone again from GitHub and git checkout <some-branch-name>, then I git log and will see commits done today instead of 12 days old.

But I don't want to have to set everything up again using npm i etc etc, so I would hope to have the old directory be able to see the current branch content.

A branch name remembers some specific commit for you. A tag name does the same thing. The difference between the two (branch name vs tag name) is that Git, and Git users, are expected to move branch names to newer commits.

In your case, you would simply run:

  • git fetch or git fetch origin: the origin part is the name of a remote, which is mainly just a short name for a URL. This tells your Git to call up another Git—the Git you cloned from originally—and to bring in new commits that you do not already have. It remembers where the other Git's branches are, using your remote-tracking branch names. So if they have a branch named master, you get one named origin/master, which remembers where their Git's master was on the last git fetch.

  • git log on the remote-tracking branch name(s): for instance, git log origin/master to see what is in origin/master after you have updated your origin/master from the other Git's master.

  • git merge or git rebase: these merge with, or rebase (copy) your commits, on to some other branch, such as a remote-tracking branch.

If you create a new branch (as you did with git checkout -b), this new branch probably does not have an upstream setting. You can choose one (and only one) of your remote-tracking branches to set as its upstream. For instance, if your new branch some-branch-name should have origin/master as its upstream:

git branch --set-upstream-to=origin/master some-branch-name

Once you have set this, your Git knows that when you are on your some-branch-name branch, a plain git merge or git rebase should use your origin/master to do the merge or rebase.

Once you know how all this works, you can combine the git fetch command and the second (merge or rebase) command using the git pull convenience command. I recommend delaying this until you are familiar with the individual commands. Sometimes, the second command (of the two commands that git pull runs for you) fails. When this command fails, you need to know what command you were running. If you know only git pull you will not know what second command you were running!