伺服器設定文件，會保存諸如資料庫使用者名稱、密碼等敏感資訊。 在多人開發過程中，這些敏感文件如果提交在版本控制系統裡，會造成隱憂。 有沒有好的處理方法呢？
拥有18年软件开发和IT教学经验。曾任多家上市公司技术总监、架构师、项目经理、高级软件工程师等职务。 网络人气名人讲师，...
辦法其實很多，有兩種較常用。
第一種是設定檔不提交真實內容，只提交一個範本檔案。每個開發者克隆之後按照自己的環境補完配置文件，這樣自然而然就獨立出來了（需更改文件名並忽略有效配置文件）。
如果設定檔很大配置很多，此法會讓每個人都覺得很麻煩。可以進一步把需要獨立配置的選項單獨分一個文件，可以共享的配置文件提交，需要獨立的配置文件則模板化，這樣可以省點事。不過使用設定的時候需要對兩類文件進行合併處理──這個可以寫腳本來做。更進一步的，可以允許獨立設定檔覆蓋同名配置項，這樣還可以做到配置可自訂化。
第二種方法則是換一個思路，設定檔正常提交，不用分也不用改。但凡遇到敏感資訊的一律不寫明文，可以用比方說系統環境變數來取代。每個開發者需要在克隆程式碼之後設定必須的環境變數（這件事情本身可以單獨來管理，和具體專案不牽扯），而專案本身的運作則依賴這些環境變數的存在及其驗證有效性等等。
第一種方法在各種開源專案裡用的比較多；第二種方法則有一定的門檻，所以多用於固定團隊專案。個人偏好第二種，因為我可以簡單地使用腳本來控制一切，而且敏感資訊獨立於項目，安全性更高一些（第一種方法裡，不巧總能碰到壞事的小白…），可重用性也更高（比如說多個項目都要用到資料庫，我只需要本地設定一次相關的環境變量，這些項目都能使用）。
這個加在忽略檔案清單中 ---
辦法其實很多，有兩種較常用。
第一種是設定檔不提交真實內容，只提交一個範本檔案。每個開發者克隆之後按照自己的環境補完配置文件，這樣自然而然就獨立出來了（需更改文件名並忽略有效配置文件）。
如果設定檔很大配置很多，此法會讓每個人都覺得很麻煩。可以進一步把需要獨立配置的選項單獨分一個文件，可以共享的配置文件提交，需要獨立的配置文件則模板化，這樣可以省點事。不過使用設定的時候需要對兩類文件進行合併處理──這個可以寫腳本來做。更進一步的，可以允許獨立設定檔覆蓋同名配置項，這樣還可以做到配置可自訂化。
第二種方法則是換一個思路，設定檔正常提交，不用分也不用改。但凡遇到敏感資訊的一律不寫明文，可以用比方說系統環境變數來取代。每個開發者需要在克隆程式碼之後設定必須的環境變數（這件事情本身可以單獨來管理，和具體專案不牽扯），而專案本身的運作則依賴這些環境變數的存在及其驗證有效性等等。
第一種方法在各種開源專案裡用的比較多；第二種方法則有一定的門檻，所以多用於固定團隊專案。個人偏好第二種，因為我可以簡單地使用腳本來控制一切，而且敏感資訊獨立於項目，安全性更高一些（第一種方法裡，不巧總能碰到壞事的小白…），可重用性也更高（比如說多個項目都要用到資料庫，我只需要本地設定一次相關的環境變量，這些項目都能使用）。
這個加在忽略檔案清單中 ---