我已經在一個存盤庫上作業了一年多，沒有任何問題。其他人第一次致力于它，當我嘗試拉取他們的更改時，我收到了以下訊息：
error: The following untracked working tree files would be overwritten by merge:
.DS_Store
我.DS_Store在我的存盤庫中的任何地方都找不到呼叫的檔案。我添加.DS_Store到我的.gitignore并提交了這些更改，但我仍然收到錯誤。然后我git stash之前嘗試過跑步，git pull但這也無濟于事。我如何解決它？
在 Macbook Pro 上使用 RStudio。
uj5u.com熱心網友回復：
.DS_Store是一個隱藏檔案（因為.），您無法看到它。在終端中，您可以使用ls -la.
然后，如果你已經推.DS_Store送到你的倉庫，你必須取消跟蹤這個檔案，然后只有未跟蹤的檔案才會被忽略.gitignore。
要取消跟蹤檔案，請執行git rm --cached .DS_Store. 然后，當在.DS_Store中正確注冊時.gitignore，您將永遠不會在遠程存盤庫中看到此檔案。
但是也沒有問題，.DS_Store用合并覆寫-file。這些檔案包含有關系統配置的資訊。對于從 Mac OS 推送到此存盤庫的每個人，將創建自己的.DS_Store. 但是通過正確添加到.gitignore，此檔案不再每次都被覆寫。
uj5u.com熱心網友回復：
其他人第一次致力于它......
“嗯，這就是你的問題！” ??
說真的，發生的事情是其他人將他們的 .DS_Store檔案放入了他們的提交中。你接受了他們的提交，所以你接受了.DS_Store應該存盤在你的 Git 存盤庫中的想法，在那個提交中。（您可能會考慮從您控制的存盤庫的每個副本中彈出此提交，并讓它們正確地重新執行，或者您可以通過將提交提取到安全的地方，洗掉檔案，在您控制的每個存盤庫中為它們修復它，并進行新的額外提交。請注意，您必須小心避免在任何“不安全”的地方檢查他們的提交。）
正如SwissCodeMen 所說，.DS_Store是一個隱藏檔案，macOS Finder 創建并使用它來存盤有關在何處以及如何顯示目錄（或檔案夾，如果您喜歡該術語）中的各種檔案和子目錄的各種圖示的資訊。 你的記錄你想要顯示的內容和位置；他們的記錄他們想要顯示的內容和位置；你可能不想要他們的，他們也可能不想要你的。然而，這種東西在被覆寫時是無害的：你可以洗掉它，讓 Finder 從頭開始??創建一個。但是，您將失去為將圖示放置在您想要的位置所做的任何仔細重新組織。
這里的關鍵概念是提交保存所有檔案的快照
每個Git 存盤庫中的每個提交都存盤每個檔案。關于這一點，有很多事情需要了解，這取決于您想要掌握的 Git 水平。使用Git需要知道的最小集合是這樣的：
存盤庫的核心是提交的集合。盡管提交包含檔案，但Git 存盤庫與檔案無關。存盤庫不是關于分支，盡管提交被安排在我們稱為分支的東西中，我們也稱為分支的不同東西——或者更準確地說，分支名稱——幫助我們（和 Git）找到提交。但最終存盤庫是關于提交的。
每個提交都有一個唯一的，但看起來隨機且無法記住的“數字”，以十六進制表示。該編號對于該特定提交是唯一的：任何其他 Git 存盤庫（無論在任何地方、出于任何目的）都不能使用該編號，除非它要存盤該特定提交。1 這就是兩個不同的 Git 克隆在相遇時如何決定一個提交而另一個缺少的提交。
每個提交存盤兩件事：
提交存盤所有檔案的快照，如本節所示。提交中的檔案以一種特殊的方式存盤：它們被壓縮——有時壓縮得非常多——并且經過 Git 化和重復資料洗掉。如果同一個檔案有數百萬次提交，則它只存盤一次。因此，即使 Git 存盤了每個檔案的每個版本，但每個版本只有一個副本，有時一個副本減少到只有幾個位元組。
請注意，盡管這樣說聽起來很有趣，但提交僅存盤它存盤的檔案。也就是說，提交
A（A代表某個哈希 ID）可能是您的第一次提交，您只有一個README.md檔案或類似檔案。所以 commitA只有一個檔案，或者那個檔案加上一些其他的骨架啟動檔案。在接下來的承諾B可能會含有更多的檔案，但A只有最初的檔案。提交存盤一些元資料，或有關提交本身的資訊。這包括諸如是誰、何時以及為什么（他們的日志訊息）之類的內容。元資料字串一起提交，以便 Git 可以從另一個提交中找到一個提交。
每一次提交，一旦完成，就完全是只讀的。（這實際上適用于 Git 的所有內部物件，并且是由于基于哈希 ID 的存盤技巧。）
因為提交是只讀的，并且有 Git 化的檔案，只有 Git 可以讀取，實際上沒有任何東西——甚至 Git 本身——都不能覆寫，你必須先 提取一個提交，然后才能處理或使用它。提取的、待處理的副本不是提交本身：它是一個副本。此副本位于您的作業樹中，您可以在其中完成作業。
當您提取提交的副本時，Git 通常會覆寫您之前的作業樹副本。也就是說，Git 必須丟棄之前選擇的提交中的所有舊檔案，并用新選擇的提交中的新副本替換它們。
對于某些檔案——您未跟蹤的檔案，無論它們是否被忽略——Git 可以只保留這些檔案。大多數情況下，這對您來說非常有用：這意味著您的 macOS Finder 可以將各種.DS_Store檔案放在整個作業樹中，只要您不添加和提交檔案，以便它們永遠不會進入您的存盤庫中的任何提交， Git 從不打擾這些作業樹檔案。
但是有些檔案正在提交中。在這里，如果某些檔案F1和F2是當前提交C，而你切換到新的目標提交T具有同一副本的F1但不同副本的F2，Git是不得不RIP檔案F2出你的作業樹并放入F2的T版本。
這同樣適用于一個.DS_Store檔案：如果你的同事/同事/別人做了提交保存一些.DS_Store檔案，而當前提交C 不會有一個.DS_Store檔案，但你的作業樹確實有一個，你有一個未跟蹤 .DS_Store檔案。 請注意，此檔案是否被忽略并不重要；重要的是你在你的作業樹中有它，并且.DS_Store在目標提交中T也有一個檔案的副本。 您已經告訴 GitT從當前提交切換到 commit ，C因此 Git 必須洗掉 您的（未跟蹤的）.DS_Store并將其 .DS_Store從T.
Git—rightly!—complains that it will overwrite, i.e., discard, your .DS_Store file. And it will, if you check out commit T. Your options are:2
- check out commit
T, overwriting your.DS_Storefile anyway; - move or save your
.DS_Storefirst so that overwriting is no longer a problem, then check out commitT; or - don't check out commit
T.
Note that you cannot fix commit T because no commit can ever be changed. You can make a new and improved version of T by checking it out, removing the .DS_Store file, and making a new commit T2, but when you do that, your existing .DS_Store file will be overwritten briefly until you remove it. (You can then put your untracked .DS_Store file back from wherever you saved it, if you like.)
如果.DS_Store由于某種原因保存和恢復檔案特別痛苦——它可能不是，但可能有其他檔案可能是這種情況——考慮使用git worktree add添加臨時作業樹和分支，在其中進行修復commit 進行更正的 commit T2，而不會觸及您現有的作業樹。在命令列中執行此操作，而無需使用任何花哨的圖形用戶界面，包括MacOS的搜索，讓搜索不會使用.DS_Store檔案中臨時增加作業樹。這種添加作業樹的技術使您可以使用所有常用的日常 Git 工具，而無需學習許多更深入的 Git 命令。
1這種對唯一性的技術要求在技術上是不可能的——通過鴿巢原理可以證明是這樣——但是提交哈希 ID的巨大規模有助于推遲不可避免的災難；我們希望它不會發生在宇宙終結之后，或者至少我們都死了，不在乎。如果當它沒有發生，宇宙毀滅ER沒有被提發生呃等待那是不對的，我們都變成青蛙？啊，是的：存在此類哈希沖突的兩個 Git 存盤庫無法再相互通信。所以，并不是真正的災難，只是很煩人。
2從技術上講，還有更多選擇。例如，您可以使用：
- 稀疏簽出，以避免在洗掉檔案并提交 make 之前簽出一個檔案
T2；或者 git read-tree,git rm --cached,git write-tree, 并git commit-tree避免T在進行 commit 時檢查commitT2。
這些解釋起來非常棘手，對大多數人來說，只使用常規的 Git 操作會更好。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/391819.html