Git 克隆導致已刪除和未跟蹤的文件

Question

我是 Git 的新用戶。

我剛剛為 Windows (10) 安裝了 Git (2.9.3)，然后我打開了 git-bash 並做了一個git clone <remoteURL> 。 使用遠程存儲庫的整個副本創建一個新文件夾，這很好。 但是后來我運行了git status ，我得到了大量deleted的文件（我想是剛剛復制的所有文件）准備to be committed ，並且存儲庫文件夾下的三個主要文件夾untracked 。 deleted的文件實際上存在於我的驅動器上！

我很確定我的 git 狀態應該是干凈的。 怎么了？

關於已刪除的文件沒有幫助（我沒有使用checkout ），關於未跟蹤的文件也沒有幫助（我沒有使用 Mac OS）。

Answer 1

我正在檢索一個路徑很長的大型項目。 我忘了設置 Git 以使用長路徑：

git config --global core.longpaths true

在此之后，克隆進行得很順利，狀態也很干凈。

Answer 2

聽起來您以某種方式加載了一個空索引。 使用命令git read-tree --empty發生這種情況的正常方式，但這不是您作為 git 新用戶通常使用/知道的。

也許克隆出了點問題。 不過應該不難修復，只需運行

git reset

並且索引應該恢復到最新提交的內容。

Answer 3

這個問題不僅讓“對 git 不熟悉”的 OP 感到困惑。 它也嚇壞了我，一個相當大的 git verteran。 :-)

感謝此處其他答案的提示，我意識到這是由 git 引起的，它碰巧無法檢出某些名稱包含當前文件系統和/或操作系統上不受支持的字符的文件。 例如，當我克隆 github wiki 存儲庫時，我遇到了同樣的錯誤，一些 wiki 頁面的文件名中碰巧包含一個: ，它們可以在我的 Linux 機器上很好地克隆，但是（事后看來）顯然不是我的 Windows 盒子。

了解根本原因使我們能夠自信地決定如何/是否解決此問題：

• 我們可以通過將那些有問題的文件名重命名為更短和/或僅包含通常的字母表來修復它。
• 或者，從技術上講，我們根本不必修復它。 如果那些有問題的文件名在他們的目標平台上沒有問題，並且我們正在處理這個 repo 的其他一些內容，我們可以像往常一樣繼續我們的工作； 我們只需要記住不要將那些丟失的文件作為刪除提交。 （去過那里，做到了；不要在家里嘗試這個。）

Answer 4

如果您在 Windows 上遇到問題，可能會根據這些禁用字符檢查您的文件名：

< （小於）
> （大於）
：（冒號）
" （雙引號）
/ （正斜杠）
\\（反斜杠）
| （垂直條或管）
? （問號）
* （星號）

或使用以下保留字之一或其中之一緊跟擴展名命名的文件： CON、PRN、AUX、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、LPT1、LPT2、 LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。

可以在此處找到更多詳細信息。

Answer 5

如果您最終到達這里並且 longpath 屬性不起作用並且您在 Windows 上運行並使用 Git Bash，那么您可能會在 Windows 中使用保留關鍵字的文件。 即，我有包含nul文件，這些文件在克隆后被刪除。 找了半天發現是這個保留關鍵字的東西。

解決方案只是重命名文件（在您可以創建它的其他機器/操作系統上）。 推送它，然后在您的 Windows 機器上重做克隆操作。

Answer 6

就我而言，我在 Mac 上的一個不區分大小寫的文件系統中克隆了 repo，但是該 repo 包含一個名為Config的文件和一個名為config的目錄，文件系統將其視為同一件事。 因此，在克隆時，它顯示文件Config已被刪除。

修復是在區分大小寫的文件系統上克隆 repo。

Answer 7

也可以是文件名中的不可見字符，請在其他系統上查看 ;)

Answer 8

我在 windows 10 上遇到了類似的問題，我檢查了其他 windows 以及 git 工作正常的地方，我的 git 版本是 2.24.xx。 我安裝了 git 2.16.x 的舊版本，它解決了問題。 試試看，讓你知道

Answer 9

將某些文件顯示為已修改的行為可能與行尾設置和使用的多個客戶端有關。 每個操作系統都以自己的方式處理行尾。 因此，如果您正在處理在多個操作系統中編輯文件的存儲庫，您可能會看到意想不到的結果

以下命令將永久解決問題

git 配置 --global core.autocrlf 輸入