我認為該git checkout命令僅更新了作業樹中的檔案。事實上，手冊頁是這樣寫的：

git-checkout - 切換分支或恢復作業樹檔案

但是，我剛剛運行了這個命令：

git checkout 11cb5b6 -- hello.txt

并且，除了更新我的作業樹副本之外，這個命令還更新了我的索引。在命令之前，git status給了我一個干凈的結果：

nothing to commit, working tree clean

但緊跟在 之后checkout，它寫著：

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   hello.txt

即作業樹檔案已更新和暫存。我錯過了什么？

uj5u.com熱心網友回復：

當您執行git checkout特定分支或提交時，臨時區域和作業目錄都會 更新。因此，該版本位于 head 的父級中，并將其復制到暫存區和作業目錄中。hello.txt

如果您沒有指定提交或分支，則 hello.txt 的內容將從暫存區復制到作業目錄。暫存區本身沒有改變。

uj5u.com熱心網友回復：

該git checkout命令是非常復雜的。它是如此復雜以至于有人最終在 Git 2.23 中將其拆分為兩個單獨的命令：

• git switch, 執行“選擇其他分支或提交簽出”操作；和
• git restore，它執行“更新索引和/或作業樹中的某些檔案”操作。

這還沒有提到幾種額外的操作模式（git checkout -m例如），¹但至少將所有“恢復檔案”選項分開，其中有很多。

git checkout正如shrey deshwal 指出的那樣，您正在使用“恢復檔案”模式，此操作將：

• 寫入您的作業樹（始終）；和
• 寫入您的索引/暫存區（有時）。

使用git restore代替 時git checkout，您可以使用-S(staging area) 和-W(working tree) 選項控制更新哪些索引/暫存區和作業樹檔案。這是不可能的git checkout：git checkout總是寫入作業樹，如果您指定提交或樹物件作為要寫入作業樹的檔案的源，也會寫入索引/暫存區。

如果您有 Git 2.23 或更高版本，請使用它git restore來執行此操作：它的操作不那么混亂且更直接。您--source為檔案指定，或讓它默認使用索引：

git restore --source 11cb5b6 -- hello.txt

這將寫入作業樹（僅）。或者，添加-S和/或-W寫入暫存區（索引）-S，和/或作業樹-W：

git restore --source 11cb5b6 -SW -- hello.txt

這將寫入暫存區和作業樹（因為-S和-W都已給出）。

相比之下，git checkout -- file使源不那么明顯（它與 中的相同git restore，但不那么明顯）并且讓您無法選擇目標（總是-W，但-S如果源是提交或樹，則會被添加）。該git restore命令還正確記錄了--overlayvs--no-overlay模式。此選項僅適用于“還原檔案”模式git checkout（現在已記錄在案，但尚不清楚它是否僅適用于此模式！）。

¹的-m選項git checkout：

• 重新創建合并沖突，或
• 在結帳期間執行合并操作，就好像您運行了一系列相當復雜的 Git 命令，這些命令以您在目標分支上結束，然后與作業樹中未提交的代碼合并。

這第二個操作有點危險：正如檔案現在指出的那樣，

使用 切換分支時--merge，分階段的更改可能會丟失。

第一個操作愉快地破壞了您在檔案的作業樹副本中開始的任何合并作業。所以git checkout -m總是“危險”的git restore方式：它會在不詢問的情況下清除未提交的作業。我有點希望這些沒有留在git switch命令中，但它們是。

僅當上述內容仍然沒有意義時才閱讀：

If this stuff still doesn't come together, you're probably missing out on a key concept in Git: how the index / staging-area really works.

A Git repository is, to a large extent, just a big database of commits. What you do with this repository is add more commits. Each commit itself is:

• Numbered. Each commit has a big, ugly, incomprehensible hash ID number such as ^{_{e9e5ba39a78c8f5057262d49e261b42a8660d5b9}} (often abbreviated, e.g., e9e5ba3). These appear random, though in fact they're entirely non-random.

• Storage: each commit stores two things:

  • A commit has a full snapshot of every file. Commits don't store changes, so when Git shows you changes, it's really doing a git diff of two snapshots.

  • A commit also stores some metadata, or information about the commit itself. This includes things like the name and email address of the author of the commit (from user.name and user.email). It includes some date-and-time stamps. It includes a log message, which git log or git show will show before any diffs. And, crucially for Git's internal operation—though we won't cover any of the details here—each commit stores a list of previous commit hash IDs. Most commits just store one such hash ID, which is the "parent" of the commit. That's how Git finds the previous commit, so that it can show you what changed.

All of this stuff inside the commit is completely, totally, 100% read-only: no part of any commit can ever be changed once it's made.² But this leaves us with a dilemma: if no part of any commit can ever change, how can we get any new work done?

Git's answer is the same as the answer is other version control systems: sure, the commits are read-only forever, but you don't do work with the committed files. We copy the files out of the commit, into a work area. You work on / with those files. That area is your working tree or work-tree. The copied-out files are ordinary read/write files, that your computer can do ordinary work on or with.

So far, none of this is particularly bizarre or incomprehensible. A commit is like an archive of files, like a tar or rar file made out of other files, but with special Gitty features like metadata and a weird random-looking number. We use git checkout or git switch to pick one: Git extracts the files, and now we can work on them.

But here's where Git gets weird. If you've used other version control systems, you are probably used to this idea: you work on the files and then you tell the VCS to commit them and it does. That would be simple, so Git doesn't do that.

When Git goes to build a new commit, Git does not use your files at all! Instead, Git uses a secret extra copy. Only it's not actually secret, and it's not usually a copy either. What it is, is hidden. This extra "copy" of each file is in what Git calls by three different names:

• The index: a meaningless term. Meaningless is sometimes good, because then there's no preconceived notion to push out of the way for some weird technical reason. But it makes it a bit hard to remember.

• The staging area: this is how you use the index, so it makes sense. But this obscures the technical details, which do matter. You need to be aware of them.

• The cache: this is the worst name of all, because it's how Git itself sometimes uses the index, but not how you use it, and doesn't cover all the ways that Git uses the index. This term is mostly defunct, except that it appears in flags like git rm --cached or git diff --cached.

Sometimes the --cached flag has --staged as a synonym: git diff --staged does exactly the same thing as git diff --cached. Sometimes they don't: git rm --staged rejects the --staged entirely. Oddly, git restore has only --staged. Getting rid of --cached entirely might be a good direction; maybe Git will eventually do that. But in any case, you need to know all three names, as "the index" appears in various places. In particular, the index has a special role during conflicted merges, and it determines whether files are tracked or untracked. We won't go into this level of detail here; we'll only talk about the index as it pertains to making new commits.

When you run git commit, instead of Git reading from your working tree to find out which files you've changed, Git simply packages up the files that are in its index at this time.³ To make that work, the initial git checkout or git switch step first fills in Git's index.

What this means is that after you've checked out some commit to work on it, you have three "copies" of each file:

• There is a read-only, Git-ified, compressed-and-de-duplicated special format version of the file in the commit.
• There is another "copy" (see below for the reason for the quotes here) of that file in Git's index / staging-area.
• Last, there's a usable copy (no quotes this time) of the file in your working tree. That's the one you can see and edit.

When Git stores a file permanently in a commit, it:

• compresses the file, so that it takes less space;
• sometimes, super-compresses the file (this happens late in the game);
• always Git-ifies the file: it's not stored as a file (with a name and other OS attributes), but rather as an internal Git blob object (nothing but a hash ID name, no modes, etc.; the names and modes are stored in additional Git objects called tree objects).

In other words, these files are Git-ified and put into a database, rather than kept as regular files. Whenever Git does this, it automatically de-duplicates the content. So even though every commit stores every file, the repository doesn't bloat up out of control when you have millions of commits, as many of the commits have the same copy of some file, and those are all shared. Instead of a copy of the file, we get a "copy" of the file, inside the commit: hence the quotes.

The index stores pre-Git-ified, pre-compressed and pre-de-duplicated "copies" in this same way that commits do. The git add command therefore:

1. reads the working tree version of the file;
2. compresses it and otherwise Git-ifies it: this produces an internal hash ID for de-duplication purposes;
3. decides whether the file is a duplicate, or not.

If the file is a duplicate, git add throws out the copy it just made: we don't need that one, we have one in the repository already. Git updates its index with the duplicate, and the file is now ready to be committed, all stored in Git's index.

If the file isn't a duplicate, git add takes the now-prepared compressed file and readies it to go into the database, sort of temporarily added.⁴ And now Git has a copy that is ready to be committed, stored in its index.

So:

• we started with some file path/to/file.ext in the index, ready to be committed;
• then we Git-ified the (real, OS-level) file file.ext in folder to in folder path with git add;
• then git add updated the index "copy" if needed, and now we have path/to/file in the index, ready to be committed.

Hence, before git add, the index contained the proposed next commit. After git add, the index still contains the proposed next commit. What git add just did was update the proposed next commit.

If you add an all new file, the same sequence happens: git add reads and compresses the ordinary OS-level file, figures out whether the contents are a duplicate or not—maybe you've added world.txt which also contains hello world, which is a duplicate of existing hello.txt for instance—and git add has updated the proposed next commit so that new file world.txt is listed there too.

In all cases, Git always has the proposed next commit set up in its index.⁵ Running git commit means use the proposed next commit as it is now, which is why you can partially stage stuff: what you're doing is adding, to the index, copies of some files that do match the working tree copies, and copies of other files that don't match the working tree copies. Since the index holds its own copies (or "copies" due to pre-de-duplication), this means there are always three "active copies" of each file:

• There is the HEAD (or current commit) copy. This one is Git-ified and can't be changed because it is in a commit.

• There is the index copy. This one is Git-ified, but can be changed, because it's only a proposed commit, not a real one yet.

• Finally, there's the working tree copy. This is the only one you can see and work on / with.

You use and modify the working tree copies. You use git add or git rm to create or remove the index copies, and then you use git commit to turn the proposed next commit into an actual commit.

²This means that git commit --amend is a lie. It doesn't amend the commit, it makes a new and improved replacement. The old commit still exists! This is true of git rebase as well. Things that, in Git, seem to change commits, don't really change them at all. You can tell by saving and comparing those hash IDs—but humans normally just sort of bleep right over them, which is a good thing: it lets us replace bad commits with better ones, without humans noticing that we did that.

³The git commit command offers a flag, -a, that means in effect: first, run git add -u, then run git commit. There are a bunch of subtleties about this, but the key item to note here is that this runs git add -u. The -u option will only update tracked files, so you can't use this for new files. Git therefore forces you to learn about git add.

⁴Git in fact just adds the object right away, and throws it away later if appropriate, but you can view this as "temporarily added" if you prefer.

⁵When you're in the middle of a conflicted merge, Git knows that you're in the middle of a conflicted merge because there are some index entries that have a higher "staging number" than staging-number-zero. In this mode, Git won't make a new commit from the index at all, so one can argue that in this mode, the index doesn't hold the proposed next commit.

標籤：混帐

上一篇：如何從命令列使用BeyondCompare，但在VS中使用VisualStudiodiff？

下一篇：即使我洗掉它，Git分支也總是神奇地出現