1、保護主分支不受直接提交的影響
主分支中的任何一次提交都應該是可以直接部署的，所以永遠不要直接提交預設分支，同時也是 gitflow workflow 成為標準的原因。使用分支保護可以幫你防止直接提交，當然，所有的事情都應該使用pull requests來管理。
2、避免基礎資訊的混亂
或許你在乙個新的環境工作，或者你並沒有注意到自己的 git 配置是不正確的，因此提交**時伴隨著錯誤的郵箱位址。如果提交沒有關聯到正確的使用者資訊，那將導致無法追溯到是誰寫的**。
保證你的 git 客戶端配置是正確的郵箱位址，並且關聯到你的 github 賬戶。評審**時注意檢查你的pull requests是否存在無法識別的提交。
3、為每個倉庫定義 codeowners
使用 codeowners 功能可以定義哪些團隊和人員被自動選為倉庫的審閱者。此功能會自動請求倉庫所有者進行審核。如今。組織擁有很多的倉庫，而 codeowners 可以選擇定義組織中的維護者。
4、從源**中分離出秘密憑證
在構建雲原生程式時，我們保護了許多的機密資訊，比如賬戶密碼、api 秘鑰、私人令牌、ssh 秘鑰等。絕對不要將任何機密資訊提交到你的**中，而應該採用從安全儲存外部注入的環境變數。
你可以使用 vault、aws secrets manager 之類的工具來管理產品中的機密資訊。
有很多超棒的工具可以識別**中的機密資訊，例如 git-secrets 可以幫助你識別**中的密碼；使用 git hooks 可以構建乙個預提交鉤子，並檢查每個pull requests中的機密資訊。
5、不要提交專案的依賴
6、從源**中分離配置檔案
建議不要將本地配置檔案提交到版本控制器，通常這些都是你不想推送到遠端的私有配置檔案，因為它們包含機密資訊。個人的偏好，歷史資訊等應該儲存在本地環境中。
7、為專案建立乙個有意義的 .gitignore 檔案
每個倉庫都必須使用.gitignore檔案來忽略預定義的檔案和目錄，它可以幫助你保護**中的機密資訊、依賴項和其他可能的差異。你可以從 gitignore.io 選擇相關的模板。
8、將死庫歸檔
隨著時間的推移，由於各種原因，我們發現自已擁有不再維護的倉庫。或許你為乙個臨時用例新建了倉庫，或者有一些包含舊的和不相關**的倉庫。它們存在的問題是相同的，這些倉庫在達到其目的之後不在被積極的維護開發，因此你不希望再維護它們或不希望其他人依賴/使用它們，最好的方式是將這些倉庫歸檔，這樣對每個人都是「唯讀」的。
9、鎖定依賴包的版本
你的依賴配置檔案中包含所有軟體包版本的資訊，以便在每次安裝應用程式時，在不破壞**的前提下保持一致的結果。最好的方式是使用配置鎖定檔案來避免差異，並確定每次都獲得相同的軟體包版本。
10、對齊包版本
雖然你使用的是相同的軟體包，但是不同的版本會使得在不同專案中重用**和測試變得困難。
尋找風險投資的十大最佳實踐
著名創業家和投資人 著名 hunch聯合創始人chris dixon近日發表博文 best practices for raising a vc round 文中列出了企業尋找風險投資應遵循的十大最佳實踐。現把此文進行編譯，全文如下 我曾經靠個人的力量尋找過了很多風險投資，也曾作為投資人或朋友觀察過...
使用GitHub的十個最佳實踐
n 主分支中的任何內容都應該是可部署的，所以不應該直接在預設分支上提交 而且gitflow工作流已成為標準。使用分支保護可以防止直接提交 當然，所有內容都應該通過pr進行管理。n n n 也許你正使用乙個新環境，或者沒有注意到的git配置不正確導致使用者使用了錯誤的電子郵件位址提交 現在，他們的提交...
使用GitHub的十個最佳實踐
主分支中的任何內容都應該是可部署的，所以不應該直接在預設分支上提交 而且gitflow工作流已成為標準。使用分支保護可以防止直接提交 當然，所有內容都應該通過pr進行管理。也許你正使用乙個新環境，或者沒有注意到的git配置不正確導致使用者使用了錯誤的電子郵件位址提交 現在，他們的提交與使用者無關，並...