我已經查看了 4-5 個關于此的其他執行緒，但無法確定我哪里出錯了。這是問題：
我有一個遠程分支，in-progress-show-hide-countries.
我登錄到另一臺尚未跟蹤遠程分支的 PC。我運行了一些東西，可能git pull，它獲取了一些東西，但我的記憶在這里變得模糊。我注意到我的本地檔案沒有遠程更改。
以下是我嘗試過的一些方法：
$ git status
On branch in-progress-show-hide-countries
Your branch is up to date with 'origin/in-progress-show-hide-countries'.
nothing to commit, working tree clean
git diff 沒有顯示代碼差異，但更改在我的 github 上絕對可見。
$ git diff in-progress-show-hide-countries...origin/in-progress-show-hide-countries
Git日志顯示我..可能？？跟蹤遠程分支
$ git log
commit 4624760c5d66df430fc3d91fc718ffd04f27e292 (HEAD -> in-progress-show-hide-countries, origin/in-progress-show-hide-countries, main)
但也許我不知道我在說什么，所以這是我的 git remote -v
$ git remote -v
origin [email protected]:XXX/fullstackopen.git (fetch)
origin [email protected]:XXX/fullstackopen.git (push)
這個執行緒（如何將本地 Git 分支與其遠程分支進行比較）表明我可以使用它git diff <local branch> <remote>/<remote branch>來查看本地分支和遠程分支之間的區別，所以我嘗試：
空輸出
$ git diff in-progress-show-hide-countries origin/in-progress-show-hide-countries
有什么線索嗎？我意識到我可以在本地洗掉所有內容并重新克隆，但這對我的學習沒有多大幫助。感謝任何建議。
uj5u.com熱心網友回復：
您應該確保您在正確的分支上，您可以使用以下方法進行更改：
git checkout -b in-progress-show-hide-countries
如果你的系統沒有真正的變化，你可以使用
git reset HEAD --hard
這將使您回傳到 Github 存盤庫上的最新提交。不要輕易使用！被重置的作業無法恢復。
uj5u.com熱心網友回復：
特技好吧，好吧，-詭計Git的許多之一是要認識到分支機構不意味著任何東西。您在 Git 中使用分支名稱來跟蹤提交。重要的不是分支，而是提交。
那些 SHA ID4624760c5d6...很重要。這些正是 Git需要的。您可以將任意數量的名稱附加到以下任一名稱上：
commit 4624760c5d66df430fc3d91fc718ffd04f27e292 (HEAD -> in-progress-show-hide-countries, origin/in-progress-show-hide-countries, main)
這表明 有 3 個名稱46247...，分別in-progress-show-hide-countries是origin/origin/in-progress-show-hide-countries、 和main。特殊名稱HEAD是“附加到”名稱in-progress-show-hide-countries，意思in-progress-show-hide-countries是您當前的分支名稱。
使用分支名稱可以避免4624760c5d66df430fc3d91fc718ffd04f27e292每次都輸入。（我不能每次都正確輸入：我用滑鼠剪切和粘貼。我有足夠的麻煩in-progress-show-hide-countries，我也剪切和粘貼。）除此之外，通過選擇一個名稱，如main或in-progress-show-hide-countries作為你的當前名稱，您安排 Git在您進行新提交時更新存盤在名稱中的哈希 ID 。所以你的名字總是記住最新的提交。一個漂亮、簡短、易于輸入、易于記住的名字，喜歡或用于 show-hide-countries 的正在進行的作業，是一個好主意......對你來說。Git 不關心名稱；Git關心的是mainwip-shc哈希 ID。
提交本身也會為您記住提交哈希 ID。因此，每當您進行新提交時，新提交都會為您記住當時哪個提交是當前提交。進行第二次新提交，新提交會記住第一次新提交。
如果我們用一個簡單的大寫字母替換每個提交哈希 ID：
... <-F <-G <-H <-- wip-shc (HEAD), main
我們可以看到附加HEAD和進行新的提交是如何作業的。記住提交總是像這樣向后指向，我們創建一個新的提交I，其父項是當前提交H：
... <-F <-G <-H <-- main
\
I <-- wip-shc (HEAD)
名稱main沒有移動，但因為我們在“分支”上wip-shc，所以名稱wip-shc 確實移動了。再做一次新的提交J，我們得到：
... <-F <-G <-H <-- main
\
I <-J <-- wip-shc (HEAD)
該名稱始終選擇最后一次提交，Git 從中反向作業。現在有兩種方法可以提交H，在這張圖中（以及在現有存盤庫中到達那里的三種方法），但我們需要的是某種方式，無論如何，到達那里以便找到它。Git 會在需要時自動向后作業。您只需要為其提供起始散列 ID — 您可以使用分支名稱（如wip-shc或main）或遠程跟蹤名稱（如 ）origin/in-progress-show-hide-countries。
你的Git會自動創建或更新遠程跟蹤名稱-theorigin/in-progress-show-hide-countries式的名字，當你的Git達到了自己的倉庫，在上origin，1，有他們串列出來的分支名稱。如果他們in-progress-show-hide-countries指向 commit H，您的 Git 會創建或更新您origin/in-progress-show-hide-countries的指向 commit H。
如果您的名稱wip-shc指向與您的名稱相同的提交in-progress-show-hide-countries，則origin/in-progress-show-hide-countries這兩個名稱將彼此同步，并且您是“最新的”。這就是全部的意思。
1令人困惑的是，Git 呼叫origin了一個remote，等等origin/main因此是遠程跟蹤分支名稱。但是，一旦它們在您的存盤庫中，它們實際上就不是分支名稱。所以我放棄了分支這個詞，并稱它們為遠程跟蹤名稱。更令人困惑的是，Git至少以兩種或三種不同的方式使用track這個詞。一個分支可以“跟蹤”一個遠程跟蹤 [branch] name，檔案要么被“跟蹤”，要么“未跟蹤”，每一個都有不同的含義。
當您的檔案不匹配時怎么辦
The files you can see and work on / with, in any clone of any repository, are not in the repository. The files that are in the repository are stored in a special, read-only, Git-only, compressed and de-duplicated form, that only Git can read and literally nothing—not even Git itself—can overwrite. These files are entirely useless for getting any new work done. So these files are not used for getting new work done.
Instead, when you select some commit to work on—with git checkout or git switch, usually—you're directing Git to copy the files out of that commit. The files come out of the commit and are de-compressed back to useful form (causing duplication, if they have duplicates). The expanded-out files go in your working tree (sometimes shortened to work-tree). These files are not in Git, even if they came out of Git.
As you work on those files, nothing happens inside Git. Those files aren't in Git, so changing them—or adding new files, or removing files; you can do whatever you want here—has no effect on Git.
At some point, though, you presumably want to use these updated files to make a new commit. To do that, you must use git add2 followed by git commit. That makes the new commit, which then updates your current branch name.
Note that your branch names are yours. They are not in any other Git repository. If you let someone clone your Git repository, your branch names become someone else's remote-tracking names (so now they can see your branch names), but they're still your branch names, which aren't someone else's branch names. Someone else's branch names are probably your remote-tracking names.
Once you make a new commit, you may or may not be using similar branch names, but now they won't be in sync. You synchronize by sending your new commit to them, and that's where git push would come in.
2You can sometimes get away with git commit -a to avoid the git add step. But doing this to avoid learning about Git's index is a bad idea: Git will eventually whack you over the head with its index, forcing you to learn about it. Learn about it before it's an emergency. Git is a pain sometimes, yes.
Names do not have to match
There are good reasons to use the same name on both "sides", as it were: it becomes pretty crazy to try to remember, e.g., my xyzzy is Fred's plugh, but René uses the name vue and Sasha calls it супеp. If everyone uses the same name, your origin/main and your main at least have the same purpose, even if the hash IDs get de-synchronized. But in some cases that's literally impossible: you might have two people you work with who both call their (different) branches tall, and hence two remotes batman and robin and you can't necessarily just one branch name on your side called tall, so you end up with tall-batman and tall-robin, or whatever.
When you use git fetch, the names don't have to match, because your Git is going to create or update remote-tracking names. You'll have origin/whatever for their branch whatever. You can use any name you like on your side.
When you use git push to send commits to origin, though, you have to end your git push with a request that they set one of their branch names. If you have branch names that don't match, like the batman and robin case, you do this with, e.g.:
git push robin robin-tall:tall
Here you write your branch name on the left side of the colon :, and their branch name on the right. (The robin in the middle here is the remote: a short name for the URL where you're sending the commits; this is the same name you use with git fetch robin, and that is where names like robin/tall comes from: your Git pastes the remote name in front of their branch name.3) If your branch names do match up, though, a simple:
git push origin somebranch
suffices: this means use the same name on both sides, i.e., send them my latest somebranch commit(s) and then ask them to incorporate those commits into their branch named somebranch.
他們可能會拒絕更新他們的分支。在這種情況下，我們會遇到更復雜的情況：我們必須找出他們拒絕的原因，并弄清楚該怎么做。但到目前為止，這是git push. 這意味著向他們發送他們還沒有的新提交，然后要求他們設定其分支名稱之一。您必須選擇要發送的提交（從冒號左側開始）和名稱，從右側開始。如果您使用相同的名稱上都兩面，你能離開了冒號，然后鍵入以下。
3它的內部實際上要復雜得多——這畢竟是 Git 的傳統，沒有什么可以像看起來那么簡單——但這就是最終效果。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/369288.html