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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章