如何在 git 中保留 png 文件而不跟蹤它們？

Question

我的 bitbucket 存儲庫中有我的自述文件所需的 png 文件。 但由於這些是二進制文件，當聲納 bitbucket 插件在它們上運行差異時，我會收到錯誤消息。

如何在不跟蹤文件的情況下保留文件？

我運行了git update-index --skip-worktree filename ，然后運行了git status但標志沒有反映。 它說 -

Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

不確定我是否需要從存儲庫中刪除文件，然后添加跳過工作樹標志。 有人可以告訴我我做錯了什么，或者是否有更好的方法來保存圖像文件而不對它們運行差異？ 謝謝你。

Answer 1

在主題行中對您的問題的字面回答：

如何在 git 中保留 png 文件而不跟蹤它們？

只是“你沒有”。 這是因為在 Git 中，被跟蹤的文件是存在於 Git 的index中的文件。

Git 的索引是您必須了解的關鍵數據結構（否則 Git 的行為是莫名其妙的）。 它的名字太籠統，太糟糕了，以至於它還有兩個名字：它也被稱為staging area ，或者有時——現在很少被稱為cache 。 這些天來，您主要在某些命令的某些標志中看到術語“緩存”，例如git rm --cached或git diff --cached 。 但是這三個術語實際上都指的是同一件事。

該索引的功能復雜且眾多，但實際上您必須了解的只是少數幾個。 主要的——這也是人們稱之為暫存區的原因——是它始終保存將 go 進入您的下一次提交的文件的副本。

“副本”一詞可能應該在此處用引號引起來，因為索引中的內容實際上是go 進入下一次提交的內容。 提交確實存儲文件，但它們以凍結、壓縮、Git 化和重復內容刪除的形式存儲它們。 這允許 Git 在每次提交中存儲每個文件。 事實上，新的提交主要存儲與前一次提交相同的文件，並且 Git 對每個文件的內容進行重復數據刪除，這意味着文件的新“副本”不占用空間。 對於索引中的“副本”也是如此：它們是預先去重的，所以只要它們與當前提交匹配，它們就不會占用空間。 ¹不過，除此之外，它們確實就像每個文件的副本一樣。

換句話說，Git 始終擁有您正在處理或使用的每個（已提交）文件的三個副本：

• 在當前提交中有一個凍結的，永久保存。 您無法更改此格式，並且它不是您可以用於任何內容的格式，但 Git 可以讀取它。

• Git 的索引中有一個“副本”，准備 go 進入下一次提交。 這個副本開始匹配提交的副本（好吧，通常無論如何）。

  此索引副本采用凍結格式，但實際上並未凍結。 如果修改工作樹副本，則必須運行git add來更新索引副本。 ²

• 最后，當然還有文件的普通讀/寫副本。 此副本位於您的工作樹或工作樹中。 這是您可以看到和使用和更改的那個，但它實際上根本不在 Git 中。 這不是提交中的副本，也不是准備好 go 進入下一次提交的副本 - 這就是為什么如果您更改此工作樹副本，您必須git add文件。

當您運行git commit時，Git 從索引中的任何內容創建新快照。 Between the time you run git checkout and the time you run git commit , you can control what's in Git's index, using git add and/or git rm . 因此，Git 索引中的文件副本可以更改，甚至完全刪除。 這會影響下一次提交，一旦你真正開始運行git commit 。 在那之前，它只是“暫存”更新的文件。

（ git status命令通過運行兩個比較來工作：

• 第一個比較告訴您當前提交和索引之間有什么不同。 任何不同的東西都是為 commit 上演的。
• 第二個比較告訴你索引和你的工作樹有什么不同。 無論有什么不同，都不會為 commit 上演。

由於存在三個副本，這就是文件可以同時被暫存和未暫存的方式：提交版本、索引版本和工作樹版本都是不同的版本。）

無論如何，我們回到跟蹤文件的定義：跟蹤文件是您的工作樹和Git 索引中的任何文件。 未跟蹤的文件是現在在您的工作樹中的文件，但現在不在 Git 的索引中。 它進入 Git 的索引是因為 (a) 它來自一個提交，和/或 (b) 你運行了git add它。 如果要在新提交中，它必須在 Git 的索引中。 如果它現在不在 Git 的索引中，例如，因為你在它上面使用git rm ，它就不會在下一次提交中。 如果您不想在該提交中使用它，那很好； 但如果您確實希望在該提交中使用它，則需要將其放回 Git 的索引中。

我跑了git update-index --skip-worktree filename ...

這個及其相關--assume-unchanged變體，只需在文件的索引條目中設置一個特殊位（必須在Git 的索引中，以便有空間設置該位）。 當該位被設置時，Git 將經常（並非總是，但經常）假裝文件的工作樹副本與文件的索引副本匹配。 然后它將不理會索引副本。 因此，如果索引副本當前與當前提交副本匹配，則設置該位可確保未來的git add不使用工作樹副本（或缺少工作樹副本）來更新索引副本。 索引副本僅保留在索引中，仍與當前提交匹配。

(When you use git checkout or git switch to switch to a new and different commit, so that Git has to update the index copies of various files, Git will not obey the assume-unchanged or skip-worktree bits, and will normally complain and如果更改索引副本會破壞工作樹中任何未提交的工作，請停止提交更改。但這至少有點危險，因為在.gitignore中列出文件可以讓 Git 有權銷毀工作樹副本.)

---

¹他們需要一點空間來保存文件名、緩存數據以及 Git 發現在使 Git 工作和 go 快速工作方面有用的任何其他內容。 它們還需要一些字節（目前每個文件 20 個字節）來保存內容 hash ID，這與 Git 的內部存儲格式有關。 這意味着列出幾千個文件的索引需要幾千 KiB 來存儲。 例如，在 Git 的 Git 存儲庫中，我們發現：

$ git ls-files | wc -l

表示索引中有 3865 個文件，並且ls -l on .git/index的索引大小為366964 （字節）。 該索引還存儲標題和尾聲以及其他項目，因此這里不能保證直接相關，但它通常平均起來非常像這樣。

²從技術上講，這個git add會立即壓縮和去重文件的內容，然后更新索引中的Blob hash ID 。 如果內容已經在其他地方的存儲庫中，則對新的准備提交文件進行重復數據刪除。 如果內容是新的，它現在是第一次在存儲庫中，可以提交。

請注意，如果git add在從工作樹中刪除文件后添加文件，Git 將在此時刪除索引副本。 git add命令實際上意味着使索引副本與工作樹副本匹配，如果工作樹副本消失，則意味着 Git 應該刪除索引副本以匹配。

當然，如果根本沒有索引副本，Git 將創建一個新的索引條目，像往常一樣對工作樹內容進行壓縮和去重。 索引現在包含文件名、blob hash ID 和緩存數據，並且索引副本現在與工作樹副本匹配。