SVN提交小結(轉)

標籤：

在我們用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檔案，用於儲存當前項目的使用者配置，可以使用記事本開啟。例如：開啟ASP.NET項目的.csproj.user檔案後會看到一項：<StartAction>CurrentPage</StartAction>，它表示當按F5開始調試，或者Ctrl+F5開始運行時，首先開啟的是VS的當前頁。

   2.2 *.suo

        *.suo解決方案使用者選項，記錄所有將與解決方案建立關聯的選項，以便在每次開啟時，它都包含使用者所做的自訂設定，比如VS布局以及項目最後編譯的而又沒有關掉的檔案用於下次開啟時用。刪除之後，團隊成員從伺服器下載下來之後再次開啟解決方案就會重建。

  3. 排除方法

     在伺服器上直接將以上的檔案或者檔案夾直接排除掉即可，不要幻想各個團隊成員會自己在用戶端排除掉：

右擊解決方案檔案夾→TorToiseSVN→Settings→General，如：

 

        在“Subversion下的”“Globalignore pattern ”中添加要排除在提交之外的檔案類型（以空格分隔）“bin obj *.suo*.user *.csproj.user”即可。

        也可右擊目標→TorToiseSVN→Unversion and add toignore list→檔案類型，逐個排除。

        排除後以後再提交整個解決方案，被排除的檔案類型都不會被提交：

 

二、提交的幾個原則  1.先更新，再產生解決方案，最後提交。   1.1 先Update整個解決方案

        團隊成員可能會修改解決方案中的多個檔案，所以更新的時候我們沒有必要（也不建議這麼做）去單個項目或者檔案去更新，否則可能更新下來的代碼由於只是部分導致產生的時候出現錯誤。

   1.2 然後保證在提交之前產生的解決方案沒有錯誤

        這個是提交之前最為重要的一步，一旦某個成員提交上了這種類型的代碼，那麼團隊中的其他人都將無法進行調試。

   1.3 最後再提交，而且只Commit自己修改的類

       只提交自己修改的類或者其他檔案，避免因為誤操作別人的類導致解決方案中的出錯。其實可以通過SVN的許可權控制各個成員負責的部分，可以精確到單個類（但這種方法也有不少局限性），這樣就可以大大減少由於誤操作引起的不必要的麻煩。

       對於新添加的類、檔案或者檔案夾等我們應該將他們所在的層進行提交（當然也可以對整個解決方案進行提交，但為了減少出錯的幾率採用此方法），提交的時候勾選上*.csproj檔案（預設是勾選的）和自己修改過的：

 

  這樣就可以解決下載的解決方案中建立的這個檔案夾未被包含在項目中的問題。

     而對於新添加的項目，則應該提交整個解決方案，方法跟上面類似。

  2.“微提交”

      每實現一個小功能或者幾段代碼，產生沒有錯誤之後就直接提交，也叫“儲存提交”。這樣可以通過SVN的版本控制，最大程度的減少因為後來的錯誤導致解決方案大範圍修改情況的發生。

  3.未經組長同意，不得擅自使用“get lock”功能

     就是對檔案或者檔案夾進行“鎖定”的功能。只有對於特別重要的，屬於只有自己能夠修改的並且經過組長統一的才能夠使用。否則其他人無法提交該檔案或者檔案夾。

  4.對SVN提交更新的資訊採用明晰的標註(類似在代碼裡寫的注釋)

     有了這個資訊之後我們如果某個版本出現了錯誤就可以清晰的看到是因為誰修改了哪些部分導致的，很方便調試還原。如：我們規定的格式是：姓名—修改內容

  5.不要提交自己不明白的代碼

     代碼在提交入SVN之後，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以後出現了問題將會成為項目品質的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的瞭解。    

     以上幾點做到之後，以後出現的問題只要是關於版本提交的基本上就能解決了。在實踐的過程中可能還會有以上問題的出現，但只要我們能夠清楚這些問題的來源，就能夠比較快速、正確的處理掉。當然，還是需要大家去養成一個良好的提交習慣才能避免給大家帶來麻煩。

 

 

 

SVN提交小結(轉)