所以，我的暫存分支有問題。我相信有人從中洗掉了一些檔案，當我嘗試將我的分支合并到其中時，“洗掉的檔案”永遠不會更新。就像我的分支在暫存之后，因此它不會更新（或放回）那些已洗掉的檔案。
由于我的分支是“最新的”，我想只是將我的分支重命名為“staging”并解決它......好吧，它現在正在暫存，但它跟蹤的是舊分支！
我如何讓 staging 成為 staging... 并讓我的舊分支回來。
這就是它向我展示的內容：
? 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
所以，我現在正在“暫存”，但它參考了“舊”分支。我使用了這些命令。我想我搞砸了。我只是想用我的分支強制或完全覆寫“分期”......但我重命名了一些東西......并且弄得一團糟。這就是我所做的。我看到這是不正確的。
```
git branch -m staging old_staging
git branch -m issue-118/customer-page staging
git push -f origin staging
```
uj5u.com熱心網友回復：
好吧，它現在正在暫存，但它正在跟蹤較舊的分支！
Git 中的track一詞嚴重超載：它確實“跟蹤”了錯誤的遠程跟蹤名稱，您會發現 Git 的各個部分使用該動詞，但 Git 的其他部分使用upstream或set-upstream一詞。這是一個更好的名稱，因為它的多載要少得多（例如，可以很容易地與已跟蹤檔案和未跟蹤檔案區分開來）。
使用“上游”和“設定上游”的措辭，您會發現git branch --set-upstream-to. 這就是您在此處尋找的命令。如果您喜歡該名稱staging當前意味著它當前意味著的任何提交這一事實，并且您希望重命名為stagingname 的上游是origin/staging，您只需要在您已經運行的集合中再添加一個命令：
git branch --set-upstream-to=origin/staging staging
這告訴 Git 將上游設定staging為origin/staging，而不是origin/issue-118/customer-page.
您也可以git push -f -u origin staging在您的git push步驟中使用。
技術細節（可選）
Git 存盤庫中的分支名稱特定于該Git 存盤庫（該特定克隆）。其他一些 Git 存盤庫可能使用相同的名稱，而您的 GitHub、Bitbucket 或 GitLab 或任何存盤庫，您使用 name 訪問的存盤庫origin都使用相同的名稱。但他們的名字可能指不同的具體提交。（分支名稱總是意味著一個特定的提交；一個提交“到達”其父提交，然后“到達”其父提交，依此類推。）
當您使用git fetch從其他 Git 存盤庫（例如 at 的存盤庫）獲取新提交時origin，您自己的 Git 會抓取這些新提交（如果有），然后讀取它們的分支名稱，例如staging和main等等，并將這些名稱更改為您的遠程- 跟蹤名稱： origin/staging、origin/main等。然后，您的 Git 軟體會創建或更新這些遠程跟蹤名稱，以便您的 Git 存盤庫會記住他們的Git 存盤庫記得哪些提交（但他們的 Git 存盤庫正在使用origin/前面沒有的變體）。
存盤庫中的每個分支名稱都可以有一個（但只有一個）上游集。根本不需要任何分支都有任何上游。擁有一個只是一個方便的功能。
當您使用一些現有的遠程跟蹤名稱，例如，在您自己的存盤庫中origin/develop創建一個新--guess分支時，使用該模式git checkout和git switch提供的模式（默認情況下處于啟用狀態），您的 Git 軟體將創建該分支并立即將其上游設定為對應的遠程跟蹤名稱。因此，如果您git switch develop在還沒有a時使用develop，并且您的 Git 看到您確實擁有origin/develop，您的 Git 會猜測您打算創建一個新develop的，它origin/develop作為上游并origin/develop選擇現在選擇的相同提交。這是實際中的or操作：git switch -c name --track origin/namegit checkout -b name --track origin/name--track猜測代碼暗示了標志（意思是，設定上游）。1
當您創建一個新分支時——一個全新的，沒有相應分支的分支origin——例如一個用于新功能或錯誤修復等的分支，在另一個Git 存盤庫中還沒有任何具有該名稱的分支。因此fix/bug-1234，例如，您的 local 沒有origin/fix/bug-1234“跟蹤”（作為上游）。
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,3 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.
1The 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. ?? More seriously, it's because --track is for a new branch and --set-upstream-to is for an existing branch. Also, "set as upstream" is tough to verb well.2
Meanwhile, the reason it's --set-upstream-to in git branch, but just --set-upstream elsehwhere, is due to a historical mistake: the initial attempt to add --set-upstream to git branch produced an unfortunate result. The --set-upstream option to git branch now tells you to use --set-upstream-to instead.
2As Calvin said, "Verbing weirds language." What would you put here? --upstreamify?
3Having to type in two commands would be such an awful burden, wouldn't it? ?? But the -u option is convenient. You can do it on every git push, or just with the ones that actually need to set or change the upstream: redundantly resetting the upstream is harmless.
Additional notes
To see how a branch name means one particular commit, run git rev-parse:
git rev-parse staging
git rev-parse old_staging
Each command will spit out one hash ID.
This applies to remote-tracking names as well:
git rev-parse origin/issue-118/customer-page
You can also find out the upstream setting of some branch using git rev-parse:
git rev-parse --symbolic-full-name main
which will print refs/heads/main if you have a branch named main (use master if you have master instead, and so on); and:
git rev-parse --symbolic-full-name main@{upstream}
will show the full name (including the refs/remotes/ prefix) of the remote-tracking name that main has set as its upstream. The @{upstream} suffix can be shortened to @{u}, and in place of a branch name, you can use HEAD to mean "the current branch name, whatever it is", so:
git rev-parse --symbolic-full-name HEAD@{u}
will tell you what the upstream is of the current branch, if there is an upstream for the current branch. If not, you'll get an error like this one:
fatal: no upstream configured for branch 'main'
Configuring an upstream gives you some shortcuts, and extra information, and that's most of what it does. Note that, depending on your push.default setting, it might include a very important shortcut: the default push.default setting, if you have not set it, is simple.4 This setting requires that you use git push -u origin HEAD or git push -u origin branch for the initial push so that you can just run git push with no arguments later. (If you set push.default to current or matching, this protection goes away, but it's very easy to slip up with these.)
4If you are using a pre-2.0 Git, this may not be the case. The old default default was matching. With this setting, a lot of people had a bad time. The best thing to do here is to upgrade.
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/443888.html
標籤：混帐