用於 git 中的大型項目的 Django 遷移文件（最佳實踐）

Question

我與 Django 項目中的一個團隊合作，在本地 git 中使用相同的數據庫。 我們發現 django 遷移存在很多問題，特別是當團隊很大時。

所以我們決定為每個開發人員制作數據庫，有時開發人員會刪除他們的遷移文件以解決遷移的一些問題。

我們在 Django 遷移文件中遇到了很多沖突，我們決定將遷移文件添加到 gitignore。

然后所有的工作變得更加順利。 但是我們遇到了一些問題，我們丟失了遷移文件的 git 歷史記錄，這給從特定 git 標簽更新項目版本帶來了問題。 此外，每次我們在 git 中“簽出”時，它都會刪除遷移文件。

我提出了以下建議，但我確實找到了答案

使本地存儲庫跟蹤的遷移文件在遠程存儲庫中被忽略。

有人強迫這個問題嗎？

Answer 1

鏈接的可能副本很好地回答了是否應該提交遷移文件的問題。 這個答案與此無關：它與您提出的解決方案有關。

讓某個特定存儲庫“跟蹤”某些文件的想法有些荒謬。 在 Git 中，當且僅當該文件當前位於 Git 的 index 中時，才會跟蹤該文件。 因此我們需要解決這個問題：

Git 的索引中的文件是什么時候？

簡單的答案很簡單——太簡單了——而且令人困惑和無益：當文件在 Git 的索引中時，一個文件在 Git 的索引中。 不過，文件 go 一直在 Git 的索引中進出。

Git 索引的目的是幫助你構建下一個提交。 現在在 Git 索引中的文件——並且從一個時間點到下一個時間點都會發生變化——是你下一次提交中的文件。

git add命令將在適當的條件下，從您的工作樹中復制一個文件（您可以查看和處理/使用的文件在您的工作樹中）到 Git 的索引。 如果 Git 的索引中已經有一些具有該名稱的文件，則該副本將被踢出索引，以便可以復制工作樹副本。如果 Git 的索引中沒有具有該名稱的文件，則現在添加該文件到 Git 的索引。 這個副本一旦復制到Git 的索引中，即使您更改或刪除工作樹副本，也會保留在Git 的索引中：這些是單獨的副本。 ¹

在其他情況下， git add將不執行任何操作，甚至會刪除文件的索引副本。 使用git rm --cached將刪除文件的索引副本，使用git rm將刪除索引副本和工作樹副本。 所以你有幾個 Git 命令可以影響索引副本： git add ，可以替換或刪除它， git rm ，可以刪除它。

git add做這些事情的條件有點復雜，但要簡單易用：

• git add一個全新文件將其添加到 Git 的索引中；
• git add a updated-in-working-tree file 踢出舊副本並添加新副本； 和
• git add已刪除文件（您從工作樹中刪除的文件，但未使用git rm執行此操作）刪除索引副本。

所以git add “手段”使索引副本匹配工作樹副本。

git add的條件在文件 (a)尚未在索引中並且 (b) 在.gitignore中列出時發生（除了可能發出未添加文件的警告）。 條件 (b) 表示即使我告訴您添加文件也不添加。 這不會影響索引中的文件——參見條件 (a)——因為，好吧，文件在索引中。 但是它可能已經到了那里，它現在就在那里，所以git add將更新它以匹配工作樹。

但是文件進入 Git 索引還有另一種關鍵方式，那就是：每當您提取（ git checkout或git switch ）整個提交時，Z0BCC70105AD279503E31FE7B3F47B6將提交文件讀取到您的工作索引作為提交. 這意味着簽出具有遷移文件的提交會將該文件放入 Git 的索引中。 提交控制索引中的文件。

The commits are what two Git repositories share, when you connect them up with git fetch , git pull , and/or git push . 一個提交，一旦做出，就不能以任何方式改變。 因此，如果有人——任何人——曾經提交過一些遷移文件，並且您git checkout出該提交，那么該文件會同時出現在您的工作樹和 Git 的索引中。 如果您隨后從該提交切換到該文件不在該文件中的其他提交，則 Git 將從 Git 的索引和您的工作樹中刪除該文件。

簡而言之，一旦提交，文件就永遠存在。 從有文件的提交移到沒有文件的提交，意味着刪除文件。 從沒有文件的提交移到有文件的提交，意味着添加文件。 這不是可選的。 它總是發生，每次。 文件進入 Git 的索引或從 Git 的索引中出來； 它現在被相應地跟蹤或不跟蹤。

您可以在切換到或退出此類提交后，隨后使用git add和/或git rm更改Git 的索引。 這將改變文件的跟蹤性。 但是切換到另一個提交或從另一個提交更新了 Git 的索引，改變了文件的跟蹤性。

---

¹但是，索引副本以 Git 的壓縮和去重格式存儲，准備好 go 進入下一次提交。 這意味着如果您使用各種 Git 調試工具來定位內部 object 並轉儲其字節，它們將與工作樹副本的字節不匹配。 這是一種無損壓縮方案，所以字節都在那里。 只是由於 Git 使用的壓縮和重復數據刪除技巧，它們可能占用很少甚至不占用磁盤空間。

---

底線

您應該從所有這些中得出的結論是文件的“跟蹤性”不取決於存儲庫。 這取決於個人 commit 。 每個提交都有一些文件。 提取該提交提取那些現在被跟蹤的文件。 每個提交都沒有其他文件。 如果這些文件位於您的工作樹中，則提取該提交將刪除這些文件，因為它們是從確實具有它們的提交中提取的。

這一切都由Git 索引的內容控制，因此可以（但非常痛苦）檢查一些提交，獲取一堆被跟蹤的文件，然后使用git rm --cached從 Git 的索引中刪除其中一些文件這樣 Git 就會忘記他們是從那個提交中出來的。 切換到缺少這些文件的其他提交會將這些文件留在您的工作樹中。 但是重復這樣做非常容易出錯。 不要這樣做。 你會后悔的。