這是我的提交日志，我想切換回特定的提交 id（例如 Second），當我使用 git checkout 時，沒關系，但是，我不再能夠切換回最后一次提交（第四）。
HEAD 指向第二次提交，然后當我記錄我的提交時沒有任何內容。
如何在不洗掉歷史記錄的情況下在提交之間切換？
commit 61c71a9e5a6d9e29a4172e687172dd4b8523eb4a (HEAD -> main)
Author: mohhhe <[email protected]>
Date: Fri Feb 25 19:08:36 2022 0330
Fourth
commit 9c3e8919cfa2c970f14056eef34ca12b49025f65
Author: mohhhe <[email protected]>
Date: Fri Feb 25 19:08:13 2022 0330
Third
commit d33795596001197f382038a72d20faf0cfbe7ab7
Author: mohhhe <[email protected]>
Date: Fri Feb 25 19:07:55 2022 0330
Second
commit 2fe7b1d8270fcfb41d73e69293da10734e37b069
Author: mohhhe <[email protected]>
Date: Fri Feb 25 19:07:39 2022 0330
First
uj5u.com熱心網友回復：
小巷類比
想象一下，你在一個大城市的一條狹窄街道或小巷的入口處，周圍是摩天大樓。順著小巷往下看，你可以看到一連串的垃圾箱。現在，沿著小巷走到一半，向前看。一半的垃圾箱不見了！他們去哪兒了？無處：他們就在你身后。
同樣的想法也適用于這里：Git 沒有洗掉你看不到的提交。你只是看不到他們。回到可以看到它們的有利位置，您將再次看到它們。
現實，如它所是
在 Git 中，提交是一個由兩部分組成的物體：它包含所有檔案的快照——好吧，是 Git 知道的所有檔案，在你（或任何人）制作該快照的時間——以及一些元資料。每個提交都有編號，帶有一個大的、丑陋的、看起來隨機的哈希 ID，如61c71a9e5a6d9e29a4172e687172dd4b8523eb4a您的輸出所示。
哈希 ID 是 Git查找提交所需的。提交本身存盤為一堆部分，使用提交物件和其他內部支持物件。您在此處看到的哈希 ID 是提交物件本身的哈希 ID，它僅包含元資料：快照位于樹物件中，該物件還有更多子物件。但是您通常不需要知道這一點；你需要知道的是 Git 有一個很大的資料庫來保存它的所有物件，每個物件都有編號，而且 Git 本身需要編號來檢索物件。1
然而，人類在數字方面非常糟糕。那四個哈希 ID 又是什么？無論如何，不??值得記住它們。Git 為您提供了一種非常快速的方法來查找這四個哈希 ID 中的一個： name main，您很容易記住，它可以找到其中一個哈希 ID。
隨著時間的推移，main找到的一個哈希 ID 可能會發生變化，但現在，它會61c71a9e5a6d9e29a4172e687172dd4b8523eb4a為您和 Git 找到。該提交是分支上的最新main提交。這是根據定義，因為名稱main包含該 ID。因此，如果您希望 Git 在 上找到最新的提交main，您可以簡單地向 Git 詢問main，Git 會查找名稱main并找到該 ID，從而找到該提交。
如果以及當您進行新的提交時，這就是 Git 將執行的操作（以某種順序或其他順序；您并沒有真正了解這是否有任何特定的順序）：
制作 Git 知道的每個檔案的快照。要讓 Git 看到你對 Git已經知道的檔案所做的任何更新，你必須在它上面運行。要讓 Git 看到您創建的任何新檔案，但直到現在還不存在，您必須在它上面運行。它還有很多東西，但這是你必須繼續運行的原因的第一個近似值：告訴 Git新快照應該使用新的或更新的檔案。
git addgit addgit add收集一堆元資料。Git 將收集的元資料包括您的姓名（在您的設定中
user.name設定）和電子郵件地址（來自您的user.email設定）。它包括精確到秒的當前日期和時間。并且，它包括當前最新的提交，不管是什么，在你所在的分支上——在這種情況下main。
Git 將所有這些寫出來以進行新的提交，該提交獲得一個新的、唯一的、以前從未使用過、永遠不會再次使用的哈希 ID。此哈希 ID 絕不能出現在任何Git 存盤庫中，除非用于標識您剛剛進行的此提交。（這就是為什么哈希 ID 如此之大和丑陋：所以它們可以是唯一的。）
Git then stores the new commit's hash ID in the current branch name. So now the name main selects your new commit—the one you just made.
1That's because this big database is a key-value store, with the hash IDs being the keys. There's a slow method of walking the entire database and getting every <key, value> pair, but this takes many seconds, or even minutes, in a big repository: far too slow to be useful. A key lookup takes milliseconds, so that's what you want Git to be doing.
Commits thus form backwards-looking chains
What this all means is that the name main automatically and always selects the last commit in the branch named main. By definition, main is the end of the street / alleyway / superhighway / motorway / whatever it is. You add new commits by making new commits while you're on that "road", and that extends the "road" a bit further.
Another way to show this is to draw the commits using uppercase letters to stand in for the real hash IDs. Here, we have your original four commits, which we'll call A, B, C, and D for short:
A <-B <-C <-D <--main
The name main will "point to" (contain the hash ID of) the last of these commits, commit D. Commit D has a snapshot—a copy of all the files, frozen for all time—and some metadata, and D's metadata says that the previous commit is commit C. We say that D points to C.
Commit C, of course, has a snapshot and metadata. The snapshot holds the files that Git knew about at the time you made C, frozen for all time, and the metadata holds the date-and-time and so on, including the hash ID of earlier commit B. We say that C points to B.
Commit B holds a snapshot and metadata too, and points backwards to commit A, which holds a snapshot and metadata. But commit A was the very first commit you made, in what had been, up until you made A, a totally-empty repository. So commit A doesn't point further backwards: it can't.
That's how your four commits are, in your repository. They can never change! They are completely read-only, and those four hash IDs are now used up forever.2 The name main points to the last one—until you make a new commit. Then new commit E springs into being, pointing backwards to D, and Git updates the name main to point to E:
A <-B <-C <-D <-E <--main
2This is technically impossible, and Git doesn't really try to prevent anyone else from getting the same hash ID except by using cryptographic trickery to make it so unlikely that we don't have to worry about it. Nobody will accidentally re-use your hash IDs. The crypto makes it hard to do it on purpose, too.
Driving back into the past
But what happens when you want to visit an old commit? You ran:
git checkout d33795596001197f382038a72d20faf0cfbe7ab7
to tell Git to erase, from your work area, all the files that are safely stored forever in commit D, and go back to commit B: extract the stored-forever files from commit B into your work area. Git did that, and then git log showed you commits B and A and stopped. Why?
Git uses your HEAD to be able to see things
Git has a very special name, HEAD, that is not a branch name at all.3 Instead, this name HEAD is normally attached to a branch name. That's what your first git log shows:
commit 61c71a9e5a6d9e29a4172e687172dd4b8523eb4a (HEAD -> main)
Git has the name HEAD "pointing to" the name main here. I like to draw it this way instead:
A--B--C--D <-- main (HEAD)
with the name HEAD "attached to" the name main. (I also got lazy about drawing the arrows between commits. Just remember that the connecting lines, from A to B to C to D, are really backwards-pointing arrows.)
Running git log tells Git: First, use HEAD to find a commit. Since HEAD is attached to main, Git uses main to find commit D. The git log command then shows you commit D—well, shows it by default; there are options you can give git log to change this—and then follows D's arrow back to C and shows C. Then git log follows C's arrow to B, and shows B, and follows B's arrow to A and shows A. Commit A has no backwards arrow, so git log can finally stop.
When you git checkout a commit by its hash ID, however, Git goes into what Git calls detached HEAD mode. Here, the name HEAD is no longer attached to a branch name. Instead, it points directly to a commit. If you choose commit B, you get this:
A--B <-- HEAD
\
C--D <-- main
The git log command works as before: it uses HEAD to find a commit. But this time HEAD finds commit B, not name main and then commit D. So git log shows B, and follows B's arrow back to A and shows A, and then runs out of commits to show and stops.
If you want to see all your commits, you can:
git checkout main
which switches back to branch main, re-attaching your HEAD:
A--B--C--D <-- main (HEAD)
and now you're starting git log from the end of the road—the last commit on main—and you'll see all four commits. Or, you can run:
git log main
which tells git log that it should use the name main to look up the commit to start with. This will find commit D, even though HEAD is still pointing directly to commit B.
3It's technically possible to create a branch named HEAD. Don't do it.
More than one branch name
Once you understand the above, you're ready to handle multiple branch names. Suppose we have this:
A--B--C--D <-- main (HEAD)
and we create a new name, such as develop, pointing to commit D, by running:
git branch develop
We now have this:
A--B--C--D <-- develop, main (HEAD)
That is, both names, develop and main, point to commit D. The special name HEAD is currently attached to the name main though. Let's make a new commit on main, commit E, and draw it in:
E <-- main (HEAD)
/
A--B--C--D <-- develop
Commit E is now the latest commit on main, while commit D continues to be the latest commit on develop.
If you now run:
git checkout develop
or:
git switch develop
to switch to branch develop, we get:
E <-- main
/
A--B--C--D <-- develop (HEAD)
Commit E still exists, but Git will take all of E's files out of our work area, and put in all of D's files instead. The name HEAD is now attached to the name develop, not the name main, so git log will show commits D, C, B, and A and then stop. Running git log main will show E, then D, then C, and so on.
Note that commits up through D are on both branches. But now that we're on develop instead of main, let's make another new commit:
E <-- main
/
A--B--C--D
\
F <-- develop (HEAD)
Commits A through D are still on both branches, but now main and develop each have one commit that the other branch doesn't have. The two names pick the latest commits, which are E and F. E is the latest main-branch commit and F is the latest develop-branch commit. They're both "the latest commit"! If we make another new commit on develop, like this:
E <-- main
/
A--B--C--D
\
F--G <-- develop (HEAD)
then the two latest commits are now E and G. Each branch name "means" that particular commit, which is by definition the latest commit on that branch. Moreover, all the commits you (or Git) can find by starting at that "latest" commit, and working backwards, are "on" that branch. So when we have:
I--J <-- br1
/
...--G--H <-- main
\
K--L <-- br2
we have three latest commits, and commits up through H are on all three branches. Pick one name to check out, and that's the set of commits you'll see with git log; the files in your work area will be those from that latest—or tip—commit.
Note that the commits never change: once you make a commit, it is good forever. However, we find commits through branch names, and those do move about. If we take the last example and move the name br2 back one hop:
I--J <-- br1
/
...--G--H <-- main
\
K <-- br2
\
L ???
we may never be able to find commit L again. It has become "lost", as there's no way to recover its hash ID. As long as we can find J and K, though, we can't lose H, even if we completely delete the name main. Deleting that name just means we no longer have direct access to commit H: we have to find it by working back one step from K, or two from J.
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/435168.html
標籤：混帐