我剛開始學習 Git。現在我所知道的是，在提交到主存盤庫之前，“快照”被添加到暫存區。問題是，我是否應該關心這些“快照”可以在暫存區停留多長時間？例如，當我關閉我的電腦時，所有資料都會被洗掉嗎？

如果暫存區內容沒有生命周期，它與存盤庫本身有何不同？在這種情況下，對我來說它看起來像第二個存盤庫。

uj5u.com熱心網友回復：

請記住，只有一個停靠區。這意味著，當您切換分支時，暫存區的內容將被帶到另一個分支。-f當目標分支與暫存區沖突時，Git 甚至會拒絕切換（除非您提供 force switch ），就像本地更改沖突時一樣。

使用暫存區準備干凈的提交。一個干凈的承諾是，當你的專案編譯全自動化（單元）測驗通過。

有時您可能會在代碼庫未編譯的情況下創建更大的更改，但您的部分作業應該是安全的。
尤其是在進行測驗驅動開發時，您經常會遇到相反的情況：您已經完成了一個微回圈（代碼庫編譯并且單元測驗通過），但是您當前的單元測驗還沒有完成。

在這兩種情況下，您都會暫存當前狀態 ( git add)。

一旦您的任務完成（專案編譯和所有測驗通過），您就將最新的本地更改添加到階段并提交暫存狀態。

是的，這樣你會得到很多相當小的提交。但這是好事：

• 小提交需要較少的詞來描述它們 -> 提交訊息的第一行通常就足夠了。這種方式git log -oneline顯示了您所做作業的檔案。

• 小提交在以下方面發生沖突的可能性較小 rebase

• 小提交使得更容易找到檔案中的某個更改，因為更改的檔案不多，提交訊息可以提供更好的線索，哪個提交可能具有該更改。

• 小提交使得通過cherry-picking將更改從一個分支轉移到另一個分支變得更容易。

畢竟，你仍然可以壁球他們后來到一個單一的承諾如果需要的話。

uj5u.com熱心網友回復：

Timothy Truckle 的回答是正確的，但我要補充幾點：

• git worktree add 不僅創建一個新的作業樹，而且創建一個新的索引/暫存區域，該區域是該新作業樹的私有物件。
• Git 版本 2.5 到 2.14 中存在一個與此相關的錯誤（在 2.15 中已修復），這是一個相當糟糕的錯誤。

錯誤在于這些添加的作業樹中的索引/暫存區確實有一個有限的生命周期，這是錯誤的。存盤在其中的某些檔案可能會在 14 天后被錯誤破壞。因此，如果您有一個 2.15 之前的 Git 并使用git worktree add，請在兩周內在這個添加的作業樹中完成您的作業。（或者更新到更正的 Git：更新足以保持他們添加的索引檔案完整；你不需要對添加的作業樹做任何事情；你只需要在暫存區被破壞之前升級。）

可選的附加閱讀

如果暫存區內容沒有生命周期，它與存盤庫本身有何不同？在這種情況下，對我來說它看起來像第二個存盤庫。

一個 Git 存盤庫，粗略地說，是一個大的提交資料庫。它們被編號（通過大的、丑陋的、看起來隨機的哈希 ID），Git 將它們從資料庫中提取出來。因此，您必須向Git提供任何提交的哈希 ID ，然后 Git 才能找到該提交。我們有分支和其他名稱，這樣我們，單純的人類，就可以使用輔助資料庫——一個將名稱轉換成數字的資料庫——來幫助我們（和 Git）找到提交，而不必記住看起來隨機的哈希 ID。

Git 中的index、staging area或（使用最舊和最壞的術語）快取實際上不是提交。它有一小部分雜項作業，因此沒有對它的單一完美描述，但是staging area之所以是一個很好的名字，是因為它在所有時間里都包含一個提議的 next commit。

（有時——在沖突合并期間——它會搞得一團糟，實際上無法提交。但即便如此，它也會持有一種提議的下一次提交。只是提議中包含太多內容，包括不能提交的額外內容被提交。在這種情況下git status會告訴你關于未合并的檔案。但是如果我們忽略這個特殊情況，并忽略索引扮演的其他額外角色——例如使用可選的“未跟蹤快取”加速git status對未跟蹤檔案的處理，例如——“提議的下一次提交”的描述就很好。）

由于存盤庫是提交的資料庫，而索引/暫存區只是一個尚未實際提交的提議提交，因此索引和存盤庫之間存在很大差異。事實上只有一個索引——或者更準確地說，每個添加的作業樹一個，加上一個原始的^1——意味著你最多只能在這里保存一個額外的提交（或 N 1，其中 N 是添加的作業樹的數量樹）。

也值得一看git status這里的作業原理：

• 有一個當前的 commit，可以使用 name 找到HEAD。這個提交——和所有提交一樣——是只讀的：它實際上不能改變。（您可以切換到其他一些當前提交，即改變其呈交的電流，但你不能改變任何承諾的內容。）

• 然后是索引/暫存區中建議的下一次提交。您可以更改此處的內容。它們以預先 Git 化的格式存盤，準備好提交：一旦檔案進入索引/暫存區，它們就已經被去重和 Git 化。

• 最后，在您的作業樹中有一些您正在處理/使用的檔案集。您也可以更改這些，因為這些只是普通檔案。 您計算機上的任何程式都可以讀取或寫入這些，而不僅僅是 Git。

所以當你運行時git status，它會做兩個差異，而不僅僅是一個。第一個差異將檔案HEAD與索引/暫存區中的檔案進行比較。 對于每個相同的檔案，Git 什么都不說。對于任何不同的檔案，Git 說staged for commit.

運行該差異后，git status還會運行第二個差異，以將索引中的檔案與作業樹中的檔案進行比較。再一次，對于相同的檔案，Git 什么也沒說。 對于任何不同的檔案，Git 說not staged for commit.

當您有一個大型專案時，這種陰暗的“隱藏檔案”舞蹈有用的原因就變得很清楚了。假設當前提交中有 10,000 個檔案。因此，索引中有 10,000 個檔案（可能正負一兩個），作業樹中有10,000 個檔案（正負一些，可能還有一堆您永遠不會提交的未跟蹤檔案）。如果git status每次都報告（兩次！）所有 10k 檔案，您將如何在所有噪音中找到有用的資料——例如，您更改了其中的三個？您需要有用的摘要，而不是其中隱藏了三個有用名稱的 9997 個未修改檔案的串列。

（如果您想要原始串列，請git ls-files --stage獲取。）

¹這種有點笨拙的措辭（為什么不只是“作業樹的數量”？）的原因是 Git 有所謂的裸存盤庫，根本沒有作業樹。這些存盤庫仍然有一個索引。因此，在一個裸倉庫中，我們有一個暫存區，但作業樹為零。添加三個作業樹，我們現在有四個帶有三個作業樹的臨時區域。

我認為在任何存盤庫中都有初始作業樹和索引/暫存區從根本上是錯誤的，并且所有存盤庫都應該從“裸”開始，然后添加作業樹，也許默認情況下是一個，但仍然作為一個附加組件。因此，真正的裸存盤庫將沒有索引，并且所有作業樹都將被“添加”，而不是在非裸存盤庫的“主要作業樹”和所有附加存盤庫之間存在奇怪的區別。但這為時已晚。對于大多數用戶來說，這將是一種區別，但它會解決一些棘手的內部問題，其中之一現在在郵件串列上引起了很多討論。

標籤：混帐 分期

上一篇：如何在git互動式登臺(add)命令中導航一級

下一篇：源分支是目標分支后面的兩次提交