使用GitHub的十個最佳實踐

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

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

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

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

你可以使用vault和aws secrets manager等工具來幫助在生產環境中進行secret管理。

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

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

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

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

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

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