將具有歷史記錄的文件移動到同一存儲庫中的新文件夾，這樣舊的提交也將在移動的文件中可見

Question

|--.git
|-文件1

git log file1 // 它將顯示文件的 git 歷史記錄

提交 61892bb913db3e9815914e062439364a33366a78 (HEAD -> main, origin/main, origin/HEAD) 作者：abc 29479669+abc@users.noreply.github.com 日期：2022 年 5 月 12 日星期四 16:52:57 +0530

Update file1

提交 a9015fbb8599f2f67da593f89634a728f04eb132 作者：abc 79279569+abc@users.noreply.github.com 日期：2022 年 5 月 12 日星期四 16:49:20 +0530

Update file1

現在我想將 file1 移動到一個文件夾 -> 文件夾/file1

|-.git
|-文件夾->文件1

並且做了-

git checkout -b dummygit

git mv file1 文件夾/file1

git 提交

git 日志文件夾/file1

提交 2596c755466152cf2d29e70bf99cabe18863a9bd9a (HEAD -> dummygit, origin/dummygit) 作者：abc abc@gmail.com 日期：2022 年 7 月 6 日星期三 23:57:11 +0530

moving file1 to folder

此文件的舊提交歷史不存在

我們如何以這樣的方式移動文件，在執行 git log folder/file1 之后仍然可以看到文件的舊歷史記錄

Answer 1

創建一個新文件夾，然后使用 git clone 克隆文件夾中的存儲庫，然后您可以刪除舊文件夾。 包含 git 提交歷史的新存儲庫。

您可以查看此 [1]：https ://johno.com/move-directory-between-repos-with-git-history

Answer 2

在 Git 中，文件沒有歷史記錄。 提交是歷史，您可以通過選擇一個或多個感興趣的特定提交來過濾歷史。

一種方法是告訴我有關文件 X 更改的提交。 也就是說，Git 會查看每個提交，一次一個，按時間倒退，就像 Git 一直做的那樣：

• commit 61892bb913db3e9815914e062439364a33366a78 ：文件 X 在此提交中更改了嗎？ （提取 parent 並提交並比較兩個副本中的文件 X）
• commit a9015fbb8599f2f67da593f89634a728f04eb132 ：文件 X 是否在此提交中更改？ （提取父級並提交並比較文件X是兩個副本）

每當 Git 遇到文件 X確實發生更改的提交時——也就是說，X 的父級副本不同，或者甚至完全丟失—— git log將顯示該提交。

那不是“文件歷史”，那是“過濾的提交歷史”，就像這不是蒙娜麗莎，它是蒙娜麗莎的形象。 沒有區別的區別？ 好吧，也許不是，因為...

git log --follow

使用git log --follow -- X ，您告訴git log它應該過濾歷史記錄，就像它對git log -- X所做的那樣，但是這一次，它應該檢查對文件文件的更改是否包括可能性該文件已重命名。 如果文件被重命名， git log --follow打印提交，就像它之前所做的那樣——但是它會停止尋找X並開始尋找O而不是O是文件的舊名稱。 換句話說，序列中的每個測試現在是do file O change in this commit而不是did file X change in this commit 。

這里有限制。 其中最大的兩個是：

• 這只能“向后”工作。 您必須知道文件的新名稱，例如運行git log --follow -- new/path/to/file 。

• 這一次只適用於一個文件。

一個較小（但仍然很大）的限制是，如果對文件的更改只是重命名，則重命名檢測效果最好。 因此，最好確保所有內容都已提交，然后重命名文件，提交該文件，然后進行所需的任何其他更改，然后單獨提交。 （如果您需要更改重命名文件的提交中的其他文件，那很好：這根本不會干擾重命名檢測。我的意思是，例如，Java 類文件必須有一個名稱與文件中許多單詞的拼寫相匹配，因此如果要重命名 Java 類，則必須將其拆分為一個不會構建的重命名提交，然后是一個修復文件的更新提交。如果您使用單個提交來重命名類並修復文件，Git 的重命名檢測器可能會認為該文件是如此不同，以至於它不僅被重命名，而且被完全刪除，並添加了一個新的和不同的文件。 )

目前沒有更好的選擇。 未來版本的 Git 可能有更好的方法來檢測重命名，但這種方法現在有效。