使用GitHub的十個最佳實踐

9.保護主分支，不要在其上直接提交程式碼

主分支中的任何內容都應該是可部署的，所以不應該直接在預設分支上提交程式碼，而且Gitflow工作流已成為標準。使用分支保護可以防止直接提交程式碼，當然，所有內容都應該通過pr進行管理。

8. 避免無法識別的提交

也許你正使用一個新環境，或者沒有注意到的Git配置不正確導致使用者使用了錯誤的電子郵件地址提交程式碼。現在，他們的提交與使用者無關，並且幾乎不可能追溯誰寫了什麼。

確保你的Git客戶端配置了正確的電子郵件地址並連結到了你的GitHub使用者。在程式碼審查期間檢查你的pr是否存在無法識別的提交。

7. 為每個儲存庫定義codeowners

使用codeowners功能可以定義哪些團隊和人員被自動選為儲存庫的reviewer。該功能會自動請求儲存庫owner進行稽核。現在，組織動輒有數十個儲存庫，codeowners可以從整個組織中選擇定義repo的維護者。

6. 將原始碼和secret憑證分離開

在構建Cloud Native應用時，我們保護了許多secret - 帳戶密碼，API金鑰，私人令牌和SSH金鑰。 千萬不要將任何secret提交到程式碼中。可以使用從安全儲存外部注入的環境變數。

你可以使用Vault和AWS Secrets Manager等工具來幫助在生產環境中進行secret管理。

有許多很棒的工具可以識別程式碼中現有的secret並防止出現新的secret。例如，Git-secrets可以幫助識別程式碼中的密碼。使用Git Hooks可以構建一個預提交hook並檢查每個pr的secret。

5. 避免在專案中提交依賴

將依賴推到遠端源將增加儲存庫大小。刪除儲存庫中包含的所有專案依賴，並讓包管理器在每個構建中下載它們。如果你擔心“依賴的可用性”，你應該考慮使用Jfrog或Nexus Repository等二進位制儲存庫管理器解決方案。檢視GitHub的Git-Sizer。

4. 將原始碼和配置檔案分離開

強烈建議不要將本地配置檔案提交到版本控制中。 通常，本地配置檔案包含secret，個人偏好，歷史記錄等私有配置檔案，你是不會想將其推送到遠端的。這些資訊應當只保留在本地環境中。

3. 為專案建立一個有意義的.gitignore檔案

每個儲存庫中都必須使用.gitignore檔案來忽略預定義的檔案和目錄。它將幫助你防止密碼，依賴關係以及程式碼中許多其他可能的差異。可以從Gitignore.io中選擇相關模板。

2. 歸檔不再維護的庫

隨著時間的推移，由於各種原因，我們的儲存庫可能已經無法維護了。也許你為一個臨時用例開啟了一個新的儲存庫（或者你想要POC一個新技術），或者你有一些包含舊的／不相關程式碼的儲存庫。 問題是相同的：這些儲存庫在達到目的之後不再被積極開發，你也不想再維護它們。最佳實踐是歸檔這些儲存庫，設定為“只讀”模式。

1. 鎖住包版本

您的清單檔案包含所有軟體包版本的資訊，以便在每次安裝應用程式依賴項時保持一致的結果，不會破壞程式碼。最佳做法是使用清單鎖定檔案以避免任何差異，並確認每次都獲得相同的軟體包版本。 否則你的程式碼元件版本不精確，不確定將在下一個版本中安裝哪個版本，並且程式碼可能會被破壞。

0. 對齊包版本

雖然你使用的是相同的軟體包，但不同版本的發行版會使在各種專案中重用程式碼和測試變得更加困難。

如果你有一個在多個專案中使用的包，請至少嘗試在不同的儲存庫中使用相同的主要版本。

原文連結：https://datree.io/blog/top-10-github-best-practices/