6個優秀的Git倉庫管理實踐
有權訪問源代碼使對安全性的分析以及應用程序的安全成為可能。但是，如果沒有人真正看過代碼，問題就不會被發現，即使人們主動地看代碼，通常也要看很多東西。幸運的是，GitHub 擁有一個活躍的安全團隊，最近，他們 發現了已提交到多個 Git 倉庫中的特洛伊木馬病毒，甚至倉庫的所有者也偷偷溜走了。盡管我們無法控制其他人如何管理自己的倉庫，但我們可以從他們的錯誤中吸取教訓。為此，本文回顧了將文件添加到自己的倉庫中的一些最佳實踐。
了解你的倉庫
Git 倉庫終端這對于安全的 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 手動添加命令終端中
如果你的項目已編譯，請抵制住使用 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 實踐，也不要忽視你克隆的倉庫中的安全威脅。Git 功能強大，但它仍然只是一個計算機程序，因此要以人為本，確保每個人的安全。
