在我們用VS進行項目合作開發的過程中，SVN的提交控制是至關重要的，由於版本沖突造成的各種麻煩咱們已經遇到的夠多了。所以，總結他們的經驗教訓，給我們也給其他人做個提醒。下面的第一部分是需要在正式開發之前需要做的，第二部分是開發的過程中需要注意的。
一、排除不必要的提交
1.將編譯性的文件排除在提交之外
由於編譯性的文件（包括obj文件夾和bin文件夾）並不是源文件，它完全可以通過存儲的源文件生成，一次提交的話會造成兩方面的影響：1. 浪費服務器存儲空間 2. 由於每個團隊成員編譯的結果可能並不一樣，大大增加了版本沖突的幾率。
1.1 obj文件夾
obj目錄是用來保存每個模塊的編譯結果，在.NET中，編譯是分模塊進行的，編譯完成后會合並為一個.DLL或.EXE保存到bin目錄下。因為每次編譯時默認都是采用增量編譯，即只重新編譯改變了的模塊，obj保存每個模塊的編譯結果，用來加快編譯速度。
1.2 bin文件夾
bin目錄用來保存項目生成后程序集，后置代碼類和其他非頁面類編譯后的DLL。它有Debug和Release兩個版本，分別對應的文件夾為bin/Debug和bin/Release，這個文件夾是默認的輸出路徑。我們可以通過：項目屬性—>配置屬性—>輸出路徑來修改。
2. 將屬於每個用戶的文件排除在提交之外
2.1 *.csproj.user
.csproj.user文件是一個xml文件，用於存儲當前項目的用戶配置，可以使用記事本打開。
2.2 *.suo
*.suo解決方案用戶選項，記錄所有將與解決方案建立關聯的選項，以便在每次打開時，它都包含用戶所做的自定義設置，比如VS布局以及項目最后編譯的而又沒有關掉的文件用於下次打開時用。刪除之后，團隊成員從服務器下載下來之后再次打開解決方案就會重新生成，所以沒有必要進行提交。
3. 排除方法
在服務器上直接將以上的文件或者文件夾直接刪除，同時要求各個團隊成員自己在客戶端將它們排除掉：
右擊解決方案文件夾→TorToiseSVN→Settings→General，如下圖：
在“Subversion下的”Globalignore pattern ”中添加要排除在提交之外的文件類型（以空格分隔）【bin obj *.suo *.user *.csproj.user】即可。
也可右擊目標→TorToiseSVN→Unversion and add toignore list→文件類型，逐個排除。
排除后以后再提交整個解決方案，被排除的文件類型都不會被提交：
減少沖突產生的幾率，我們可以做雙保險：在向服務器上傳全新的解決方案之前將以上的5種類型全部刪除，然后讓團隊成員再排除。以后大家在提交的時候按照下面的幾個原則基本上就不會出什么問題了。
備注：在Unversion and add toignore list菜單項中，有針對“****”或“****（recursively）兩個選擇，選擇第一個則僅針對本地資源進行排除；若選擇帶recursively的菜單項，上傳至SVN服務端，其他人在獲取最新版時，則會自動將相關資源排除；
二、提交的幾個原則
1.先更新，再生成解決方案，最后提交。
1.1 先Update整個解決方案
團隊成員可能會修改解決方案中的多個文件，所以更新的時候我們沒有必要（也不建議這么做）去單個項目或者文件去更新，否則可能更新下來的代碼由於只是部分導致生成的時候出現錯誤。
1.2 然后保證在提交之前生成的解決方案沒有錯誤
這個是提交之前最為重要的一步，一旦某個成員提交上了這種類型的代碼，那么團隊中的其他人都將無法進行調試。
1.3 最后再提交，而且只Commit自己修改的類
只提交自己修改的類或者其他文件，避免因為誤操作別人的類導致解決方案中的出錯。其實可以通過SVN的權限控制各個成員負責的部分，可以精確到單個類（但這種方法也有不少局限性），這樣就可以大大減少由於誤操作引起的不必要的麻煩。
對於新添加的類、文件或者文件夾等資源，我們應該將它們所在的層進行提交（當然也可以對整個解決方案進行提交，為了減少出錯的幾率采用此方法），提交的時候勾選上*.csproj文件（默認是勾選的）和自己修改過的：
這樣就可以解決下載的解決方案中新建的這個文件夾未被包含在項目中的問題。
而對於新添加的項目，則應該提交整個解決方案，方法跟上面類似。
2.“微提交”
每實現一個小功能或者幾段代碼，生成沒有錯誤之后就直接提交，也叫“保存提交”。這樣可以通過SVN的版本控制，最大程度的減少因為后來的錯誤導致解決方案大范圍修改情況的發生。
3.未經組長同意，不得擅自使用“get lock”功能
就是對文件或者文件夾進行“鎖定”的功能。只有對於特別重要的，屬於只有自己能夠修改的並且經過組長同意的才能夠使用。否則其他人無法提交該文件或者文件夾。
4.對SVN提交更新的信息采用明晰的標注(類似在代碼里寫的注釋)
有了這個信息之后我們如果某個版本出現了錯誤就可以清晰的看到是因為誰修改了哪些部分導致的，很方便調試還原。
5.不要提交自己不明白的代碼
代碼在提交入SVN之后，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以后出現了問題將會成為項目質量的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的了解。
以上幾點做到之后，關於版本提交的問題基本上就能解決了。在實踐的過程中可能還會有其他問題的出現，但只要我們能夠清楚這些問題的來源，就能夠比較快速、正確的處理掉。當然，還是需要大家去養成一個良好的提交習慣才能避免給大家帶來麻煩。
參考鏈接：https://blog.csdn.net/wlccomeon/article/details/20398923