origin/main和origin/HEAD在我的提交中是什么意思，為什么它們是紅色的？

我已經開始使用 Git，最近我學會了使用

git log --all --graph

查看我的提交歷史，我注意到一些我覺得令人擔憂的細節。例如，左邊的線是紅色的，這向我表明有問題。此外，在提交名稱之后，還有一些我無法解釋的文本。我認為這HEAD -> main意味著 HEAD 指向 main。但是還有兩個我認為是遙控器的字串（也用紅色表示有問題）？

左邊的線表示有問題，還是我讀錯了？提交編號旁邊的文字是什么意思？這三個部分是什么意思？有什么問題嗎，如果有，我該如何解決？

這是我日志中的最上面一行。是什么意思origin/main，origin/HEAD為什么它們是紅色的？

* commit 9bee2dac5bb71b843022409d33a46af52be217d4 (HEAD -> main, origin/main, origin/HEAD)

uj5u.com熱心網友回復：

Git 真的是關于提交。提交具有哈希 ID：

* commit 9bee2dac5bb71b843022409d33a46af52be217d4 (...)

那就是您在分支上的最新提交9bee...7d4的哈希 ID 。當您和其他人添加新的提交時，最新的提交將隨著時間而改變，但目前是最新的。main9bee2da...

如果 Git 沒有更簡單的方法來命名提交，這將使所有使用 Git 的人發瘋。（有人說Git 無論如何都會這樣做。）想象一下，為了得到你的提交，不得不記住這些看起來很丑陋的大東西！但您不必這樣做：Git 會將每個分支的最新提交的哈希 ID 保存在分支名稱中。

因此，存盤庫主要由兩個資料庫組成：一個（通常是最大的）保存提交并支持內部 Git 物件。這些都有哈希 ID；提交的哈希 ID 是您將處理的那些。為了幫助您（以及 Git 本身）找到提交和其他哈希 ID，存盤庫還存盤了一堆名稱：分支名稱、標簽名稱、refs/stashforgit stash等。這個大名稱表中的每個名稱都存盤一個哈希 ID，這就是存盤庫中的另一個資料庫：一組 <name, hash-ID> 對。其中一些名稱是分支名稱，這些名稱是存盤庫中的分支。

（物件資料庫中的物件是完全只讀的：一旦提交，就永遠無法更改它。名稱資料庫中的名稱存盤哈希 ID，但存盤的哈希 ID 可以隨時替換，甚至洗掉和/或創建新名稱。因此名稱會隨著時間而變化，以選擇最新的提交。我們將在此處跳過所有其余的細節，盡管它們確實很重要。）

Git 不僅僅是一個版本控制系統 (VCS)：它是一個分布式VCS。Git 通過讓我們復制存盤庫來實作這個分發技巧。我們習慣git clone這樣做。當我們克隆其他人的 Git 存盤庫時，我們得到他們所有的提交¹而沒有他們的分支。他們提交的哈希 ID 是我們此時提交的哈希 ID：任何一次提交的哈希 ID對于該特定提交是完全唯一的，并且每個具有該提交的 Git 存盤庫都使用該哈希 ID。該哈希 ID 現在是為此保留的犯罪。（這就是為什么它們如此龐大而丑陋的原因：這樣一來，您的所有新提交總是有一個新的 ID 可用。）

為了記住他們的分支名稱，我們的 Git 在我們的克隆中創建或更新我們自己的遠程跟蹤名稱。我們的 Git 軟體使用更短（比 URL）名稱來記住我們用來進行克隆的 URL。這里有一個標準的名字，origin每個人都使用，²所以他們的Git 存盤庫的 URL 存盤在 name 下origin。然后 Git 使用相同的名稱粘貼在它們的每個分支名稱前面：它們main變成 our origin/main，它們develop（如果有的話）變成 our origin/develop，等等。

因此，您的名稱只是您克隆的存盤庫具有一些分支名稱origin/*這一事實的反映。他們的分支名稱 = 您的遠程跟蹤名稱，因為您的 Git 會看到他們的名稱并更改它們，以讓您的存盤庫記住他們的分支。

因為你和他們共享提交——你從他們那里得到了所有的提交——他們origin/main記住了提交哈希 ID 9bee2da...。一旦您的git clone操作復制了他們的提交并修改了他們的分支名稱，您自己的 Git 軟體就會在您的存盤庫中創建一個新分支。您的 Git 在這里使用的名稱是. ³ 所以你的 Git 創建了你自己的來匹配你的 Git 用來記住他們的.mainmainorigin/mainmain

這意味著你有：

• 分支名稱main：這是您（目前）提交的名稱9bee2da...；
• the remote-tracking name origin/main: this is your copy of their branch name that, the last time your Git talked with their Git software and repository, named commit 9bee2da....

So when you run git log, your Git:

1. uses the name main to find 9bee2da...;
2. uses the hash ID 9bee2da... to find the commit;
3. shows the commit 9bee2da...;
4. adds, in parentheses, the decorations you saw: some in green, some in red.

(There's actually a step before step 1: your Git uses HEAD to find main. But we're leaving that part out for now.)

¹We can get less than all commits, but "copy all commits" is the way to think about this at first, at least.

²You can use something else if you want. If you do, your remote-tracking names will be a little different. But everyone else will expect to see origin, so there is no point to doing extra work to use a different name.

³You tell your Git, at git clone time, which of their branch names you want your Git to copy. To select their develop, for instance, you'd run git clone -b develop .... If you don't pick a branch name, your Git asks their Git which name they recommend, and usually that's their main or master or whatever.

Green and red, but nothing wrong

For example, the line to the left is red, which indicates to me that something is wrong.

No: Git just uses eight colors by default, namely red, green, blue, yellow, cyan, magenta, black, and white. This is all that was commonly available 20 years ago. There are some additional words allowed here, and modern Git can use 24-bit color if it's supported by your terminal (see Git pretty format colors). For the line-drawing part (see Pretty Git branch graphs), Git starts with red (and there's no easy way to configure this).

I think that HEAD -> main means that the HEAD is pointing to main.

That's correct: the special name HEAD—which is not actually a branch name—normally holds the name of some branch; when it does, we say that the name HEAD is attached to, or points to that branch name.

But then there are 2 more strings (also in red indicating something is wrong) which I think are remotes?

These are the remote-tracking names I mentioned above. git branch -a will show both branch names (which are always local, so "local branch" is redundant, like saying "ATM machine", but sometimes it feels appropriate anyway) and remote-tracking names; it prints the branch names in green by default, and the remote-tracking names in red by default. I'm not sure if this is meant as a mnemonic device ("red = remote"), but you can use it as one, if you like. (But then what does green equal? "Glocal" sounds way too much like "global". ??)

The second red name is origin/HEAD: this is your Git's copy of the other Git's HEAD, more or less. However, Git doesn't update it, the way it updates remote-tracking names.⁴ If you think their HEAD may have changed, you can run git remote set-head origin --auto to have your Git call up their Git and find where their HEAD is now. But there's very little use for origin/HEAD in my opinion, so I never bother.

⁴Every time you run git fetch origin, your Git calls up their Git again, using the URL Git saved under the name origin, and picks up any new commits they have, that you don't, and updates your remote-tracking names based on their branch names. In fact, git clone is really just shorthand for running git init git remote add origin ... git fetch origin a few more steps: it's the git fetch step that creates all your remote-tracking names initially, and gets all their commits initially. Since git fetch defaults to get the commits they have that I don't, and initially you have no commits, it initially gets all their commits. Since it doesn't create or update any branch names—only remote-tracking names—that's why git clone copies all their commits and none of their branches.

標籤：混帐

上一篇：如何撤消我的最后一次提交？gitreset--softHEAD^或gitreset--softHEAD~1都在作業嗎？

下一篇：如何安全地在master中gitrebase提交歷史