前言

雖然說 Git 為現代工程師必備的技能，但是在擔任現場工程師與顧問期間，仍遇到許多知名企業內工程師對於 Git 熟悉僅限於基本指令，當獨自開發專案或產品時可能沒什麼問題，當進入2-5 人小型團隊時就開始發生程式衝突，浪費時間在無效的解決方法，最後開始懷疑版本管理軟體可用性。

程式衝突並不可怕，良好的團隊會有一套開發流程，讓協作更加順暢：可能是盡可能切割工作至最小讓開發時間縮短或隨時從主要分支更新，找到與你程式衝突的協作者，良好的溝通可以快速解決程式衝突，而不是將解決衝突推給別人處理

建議

設定 Git ignore

Git ignore 是一個很基本且重要的設定，它能定義那些檔案不要納入版本管理，當開發人員提交與推送原始碼時，這些忽略的檔案只會保留在本地端。過去在微軟擔任現場工程師/顧問期間，經常遇到開發者 Push 開發環境設定或編譯後檔案 至 Git Repo，導致同團隊其他開發成員無法編譯程式或需要設定重新設定開發環境的情況發生，進而讓整個開發團隊產能低落。另一方面，大多數的開發者其實無法準確知道那些檔案不需要推送至 Git Repos，還好目前多數 Git Repo 服務可以依據開發者的需求，自動產生出相對應的 .gitignore 檔案，讓團隊在專案開發初期不需要經常調整 ignore 清單，如下圖的 Azure Repos：

非文字檔案上傳容量限制

另一個常見團隊問題 是將 binary 檔案上傳至儲存庫：開發人員不應該把非文字(尤其是大型 Binary 檔案)推送至 Repo。版本管理的優勢是可以比對前後差異，但無法比對 Binary 內容，此外，Binary 檔案相較於文字檔案，容量相當大，在開發人員在第一拉取程式碼或切換分支時，需要較多的等待時間。

無論是否使用 Azure Repos, GitHub, 或團隊建立的私有 Git 儲存庫服務，最終面對的是儲存空間的不足而進退兩難，盡早規劃儲存庫容量使用準則是非常重要的

儲存庫管理

多數團隊也容易忽視儲存庫管理 (Repository Management)。多數開發人員普遍認為 Git 只要可以做到 Commit, Push, Pull, Create Branch, Checkout 就已經足夠。儲存庫管理並不是這麼重要，但就管理與維運的角度來看，儲存庫管理可以增加團隊協作效率並保護原始碼安全，常見的設定包含：開源專案驗證作者信箱、工作項目與 Commit 綁定...等

使用者可以在 Project Setting > Repositories 內找到設定

使用者可以對於全部的儲存庫做設定，也可以對單一儲存庫做設定。

比較重要的兩個設定為設定預設分支與允許使用者對自己建立的分支有權限設定權限。後者會建議開啟，對於自己建立的分支可以進行更多操作，而不需要找管理者協助調整相關設定，降低管理者負擔。