Git倉庫管理的實現方法有哪些

這篇文章主要講解了“Git倉庫管理的實現方法有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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  功能強大，但它仍然只是一個計算機程序，因此要以人為本，確保每個人的安全。

感謝各位的閱讀，以上就是“Git倉庫管理的實現方法有哪些”的內容了，經過本文的學習后，相信大家對Git倉庫管理的實現方法有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！