6 個最佳的 Git 倉庫管理實踐

有權訪問源代碼使對安全性的分析以及應用程序的安全成為可能。但是，如果沒有人真正看過代碼，問題就不會被發現，即使人們主動地看代碼，通常也要看很多東西。幸運的是，GitHub 擁有一個活躍的安全團隊，最近，他們 發現了已提交到多個 Git 倉庫中的特洛伊木馬病毒，甚至倉庫的所有者也偷偷溜走了。儘管我們無法控制其他人如何管理自己的倉庫，但我們可以從他們的錯誤中吸取教訓。為此，本文回顧了將文件添加到自己的倉庫中的一些最佳實踐。

了解你的倉庫


這對於安全的 Git 倉庫來可以說是頭號規則。作為項目維護者，無論是你自己創建的還是採用別人的，你的工作是了解自己倉庫中的內容。你可能無法記住代碼庫中每一個文件，但是你需要了解你所管理的內容的基本組成部分。如果在幾十個合併後出現一個遊離的文件，你會很容易地發現它，因為你不知道它的用途，你需要檢查它來刷新你的記憶。發生這種情況時，請查看該文件，並確保準確了解為什麼它是必要的。

禁止二進位大文件


Git 是為文本而生的，無論是用純文本編寫的 C 或 Python 還是 Java 文本，亦或是 JSON、YAML、XML、Markdown、HTML 或類似的文本。Git 對於二進位文件不是很理想。

兩者之間的區別是：

$ cat hello.txt
This is plain text.
It's readable by humans and machines alike.
Git knows how to version this.

$ git diff hello.txt
diff --git a/hello.txt b/hello.txt
index f227cc3..0d85b44 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,3 @@
 This is plain text.
+It's readable by humans and machines alike.
 Git knows how to version this.

和

$ git diff pixel.png
diff --git a/pixel.png b/pixel.png
index 563235a..7aab7bc 100644
Binary files a/pixel.png and b/pixel.png differ

$ cat pixel.png
�PNG
▒
IHDR7n�$gAMA��
              �abKGD݊�tIME�

                          -2R��
IDA�c`�!�3%tEXtdate:create2020-06-11T11:45:04+12:00��r.%tEXtdate:modify2020-06-11T11:45:04+12:00��ʒIEND�B`�

二進位文件中的數據不能像純文本一樣被解析，因此，如果二進位文件發生任何更改，則必須重寫整個內容。一個版本與另一個版本之間唯一的區別就是全部不同，這會快速增加倉庫大小。

更糟糕的是，Git 倉庫維護者無法合理地審計二進位數據。這違反了頭號規則：應該對倉庫的內容了如指掌。

除了常用的 POSIX 工具之外，你還可以使用 git diff 檢測二進位文件。當你嘗試使用 --numstat 選項來比較二進位文件時，Git 返回空結果：

$ git diff --numstat /dev/null pixel.png | tee
-     -   /dev/null => pixel.png
$ git diff --numstat /dev/null file.txt | tee
5788  0   /dev/null => list.txt

如果你正在考慮將二進位大文件（BLOB）提交到倉庫，請停下來先思考一下。如果它是二進位文件，那它是由什麼生成的。是否有充分的理由不在構建時生成它們，而是將它們提交到倉庫？如果你認為提交二進位數據是有意義的，請確保在 README 文件或類似文件中指明二進位文件的位置、為什麼是二進位文件的原因以及更新它們的協議是什麼。必須謹慎對其更新，因為你每提交一個二進位大文件的變化，它的存儲空間實際上都會加倍。

讓第三方庫留在第三方

第三方庫也不例外。儘管它是開源的眾多優點之一，你可以不受限制地重用和重新分發不是你編寫的代碼，但是有很多充分的理由不把第三方庫存儲在你自己的倉庫中。首先，除非你自己檢查了所有代碼（以及將來的合併），否則你不能為第三方完全擔保。其次，當你將第三方庫複製到你的 Git 倉庫中時，會將焦點從真正的上游源代碼中分離出來。從技術上講，對庫有信心的人只對該庫的主副本有把握，而不是對隨機倉庫的副本有把握。如果你需要鎖定特定版本的庫，請給開發者提供一個合理的項目所需的發布 URL，或者使用 Git 子模塊。

抵制盲目的 git add


如果你的項目已編譯，請抵制住使用 git add . 的衝動（其中 . 是當前目錄或特定文件夾的路徑），因為這是一種添加任何新東西的簡單方法。如果你不是手動編譯項目，而是使用 IDE 為你管理項目，這一點尤其重要。用 IDE 管理項目時，跟蹤添加到倉庫中的內容會非常困難，因此僅添加你實際編寫的內容非常重要，而不是添加項目文件夾中出現的任何新對象。

如果你使用了 git add .，請在推送之前檢查暫存區里的內容。如果在運行 make clean 或等效命令後，執行 git status 時在項目文件夾中看到一個陌生的對象，請找出它的來源，以及為什麼仍然在項目的目錄中。這是一種罕見的構建工件，不會在編譯期間重新生成，因此在提交前請三思。

使用 Git ignore


許多為程序員打造的便利也非常雜亂。任何項目的典型項目目錄，無論是編程的，還是藝術的或其他的，到處都是隱藏的文件、元數據和遺留的工件。你可以嘗試忽略這些對象，但是 git status 中的提示越多，你錯過某件事的可能性就越大。

你可以通過維護一個良好的 gitignore 文件來為你過濾掉這種噪音。因為這是使用 Git 的用戶的共同要求，所以有一些入門級的 gitignore 文件。Github.com/github/gitignore 提供了幾個專門創建的 gitignore 文件，你可以下載這些文件並將其放置到自己的項目中，Gitlab.com 在幾年前就將gitignore 模板集成到了倉庫創建工作流程中。使用這些模板來幫助你為項目創建適合的 gitignore 策略並遵守它。

查看合併請求


當你通過電子郵件收到一個合併/拉取請求或補丁文件時，不要只是為了確保它能正常工作而進行測試。你的工作是閱讀進入代碼庫的新代碼，並了解其是如何產生結果的。如果你不同意這個實現，或者更糟的是，你不理解這個實現，請向提交該實現的人發送消息，並要求其進行說明。質疑那些希望成為版本庫永久成員的代碼並不是一種社交失誤，但如果你不知道你把什麼合併到用戶使用的代碼中，那就是違反了你和用戶之間的社交契約。

Git 責任

社區致力於開源軟體良好的安全性。不要鼓勵你的倉庫中不良的 Git 實踐，也不要忽視你克隆的倉庫中的安全威脅。Git 功能強大，但它仍然只是一個計算機程序，因此要以人為本，確保每個人的安全。

via: https://opensource.com/article/20/7/git-repos-best-practices

作者：Seth Kenlon 選題：lujun9972 譯者：stevenzdg988 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive