So, I was having issues with my staging branch. I believe someone deleted some files from it and when I tried to merge my branch into it, the "deleted files" would never update. Its like my branch was behind the staging and thus it wouldn't update (or put back) those deleted files.

Since my branch was the "latest" I thought to just rename my branch to "staging" and solve it...... well, it is now staging, but its tracking the older branch!!

HOW DO I just have staging be staging... and have my old branch back.

This is what it is showing me:

➜  My_Site git:(staging) git status
On branch staging
Your branch is up to date with 'origin/issue-118/customer-page'.

nothing to commit, working tree clean

So, I am on "staging" now, but its referencing the "old" branch. I used these commands. I think I mucked up. I Just wanted "staging" to be forced or overwritten completely with my branch..... but I renamed things... and made a mess. This is what I did. I see that it was incorrect.

```
git branch -m staging old_staging
git branch -m issue-118/customer-page staging
git push -f origin staging
```

CodePudding user response：

well, it is now staging, but its tracking the older branch!

The word track in Git is badly overloaded: it is indeed "tracking" the wrong remote-tracking name, and you'll find various pieces of Git use that verb, but other pieces of Git use the word upstream or set-upstream. That's a better name because it's far less overloaded (can be distinguished easily from tracked vs untracked files, for instance).

Using the "upstream" and "set an upstream" wording, you'll find git branch --set-upstream-to. That's the command you are looking for here. If you like the fact that the name staging currently means whatever commit it currently means, and you'd like the upstream of the renamed-to-staging name be origin/staging, you just need to add one more command to the set you have already run:

git branch --set-upstream-to=origin/staging staging

This tells Git to set the upstream of staging to be origin/staging, instead of origin/issue-118/customer-page.

You could also have used git push -f -u origin staging at your git push step.

Technical details (optional)

Branch names within a Git repository are specific to that Git repository (that particular clone). Some other Git repository may be using the same names, and your GitHub or Bitbucket or GitLab or whatever repository, the one you reach with the name origin, is using the same names. But their names may refer to different specific commits. (A branch name always means one specific commit; that one commit "reaches" its parent commit(s), which then "reach" their parents, and so on.)

When you use git fetch to obtain new commits from some other Git repository, such as the one at origin, your own Git grabs those new commits (if any) and then reads their branch names, like staging and main and whatever, and changes those names to become your remote-tracking names: origin/staging, origin/main, and so on. Your Git software then creates or updates these remote-tracking names, so that your Git repository will remember which commits their Git repository remembers (but their Git repository is using the variants without origin/ in front).

Each branch name in your repository can have one (but only one) upstream set. There's no requirement that any branch have any upstream at all. Having one is just a convenience feature.

When you use some existing remote-tracking name, such as origin/develop, to create a new branch in your own repository, using the --guess mode that git checkout and git switch offer (and it's on by default), your Git software will create that branch and immediately set its upstream to the corresponding remote-tracking name. So if you use git switch develop when you don't yet have a develop, and your Git sees that you do have origin/develop, your Git will guess that you meant to make a new develop that has origin/develop as its upstream and selects the same commit that origin/develop selects right now. This is the git switch -c name --track origin/name or git checkout -b name --track origin/name operation in action: the --track flag (meaning, set an upstream) is implied by the guess code.¹

When you create a new branch—one that's all new, that has no corresponding branch over on origin—such as one for a new feature or bug fix or some such, there isn't any branch with that name in the other Git repository yet. So your local fix/bug-1234, for instance, has no origin/fix/bug-1234 for it to "track" (have as an upstream).

As a result, for a new branch like this, you must first git push the commit(s) (if any) to origin, then—at the end of that git push—have the other Git software, working on the origin repository, create the branch name there. If and when that succeeds, your own Git software will automatically create your origin/fix/bug-1234, and now you can set an upstream. So that takes two steps: git push origin fix/bug-1234 followed by an appropriate git branch --set-upstream-to.

To avoid having to run two commands,³ git push has the -u flag (with longer spelling --set-upstream). This flag tells git push that if the push succeeds, thereby creating or updating the remote-tracking name, git push should run the git branch --set-upstream-to for you.

¹The reason it's --track in git checkout and git switch, but --set-upstream-to in git branch, is that the core Git team like to confuse everyone.