使用Git管理svn項目代碼

如果你們公司的項目代碼是用svn來進行統一管理的，但是你又想使用git的開分支功能進行本地管理的，那麼以下的介紹将會給你些許提示（如果有更好的解決辦法，歡迎大家提出）

情景描述 ：我們開發人員的一個理想開發的流程，就是【序列化】開發一個個需求，然後與前端聯調，差不多就送出到svn代碼。但是，實際上我們可能遇到的不一定都是序列化的。

以下内容是為了說了本地使用git分支的好處，若知道可以直接跳過

情景一： 當A開發【角色法寶】需求做到一半，還沒自測，這時候測試回報說【角色技能】子產品出bug了。你不得不停下手上需求開始解決bug檔案，但是A的代碼寫到一半，代碼還沒能通過編譯，自身正在開發的代碼又可能因為協定變化或者修改與bug相關的檔案，腫麼解決？ 傳統純使用svn思路一： 1、盡快解決自身需求内容，先讓其能夠編譯通過，并且不影響其他人正常測試，并且送出到svn上，再開始解決bug。 2、因為公司的svn正常隻開放trunk目錄權限，并且大部分的公司也很少允許我們在遠端的svn建立自己的分支，是以為了更快處理問題。直接checkout一個無污染的項目代碼，開始在上面找問題。 傳統純使用svn思路一存在弊端： 1、開發人員不得不為了讓内服正常執行，而做出一系列對 内服的操作，如修改測試用例不讓其報錯，清檔或者是轉換舊資料……但是這些都會影響開發人員不能第一時間去處理存在問題（如果是緊急問題，将會影響更大）。

2、【傳統純使用svn思路2】的政策對于回饋bug确實比思路一好，但是本地又要多元護了一個目錄。久而久之，本地可能會出現十多個目錄，這樣的也是不利于尋找問題的。

情景二： 當後端B開發完成【幫派】功能了，并且寫了部分測試點測試，但是前端還沒開始開發，後端想開發其他需求，腫麼辦？ 傳統純使用svn思路二： 1、代碼留在本地不送出至svn，然後開始做其他需求，等前端完成了，再開始回過頭來跟前端聯調。 2、送出代碼，并開始開發其他需求。 傳統純使用svn思路一可能存在弊端： 1、當開發其他需求，有可能會出現修改同一個檔案（如腳本自動生成的檔案cfg_init_module.c），這時候送出代碼又要考驗開發人員的眼力了，一不小心，一個需求單子，可能送出了兩個需求的一小部分内容（影響後續遷版本合并操作） 2、這種開發應該是我們開發中很常見的方法，但是會有潛在問題。 新需求有可能寫到一半，後端其他同僚說XXX功能出問題了，請修複一下。（影響到其他人正常體驗） 或者發現自己原本覺得可以的資料結構突然發現不太适合，但是已經送出到debug了。隻能清除該需求的資料。（如：開發的是将領羁絆，但是資料又存儲在将領總資料中，這時候還要清除将領資料才能正常執行，影響非常大。）

說了這麼多，其實就是為了說明在本地使用 git的分支效果的便捷性，如果我們在本地使用git來管理我們svn代碼，将開發多個任務時候将得到更好的技術援助： 應對原情景一： 非常友善，任何一個新開發的需求都在master中開分支，測試說将領職能子產品出問題了。 1、我們隻需要暫時commit一下法寶的代碼（存檔） 2、切換到技能分支，更新一下代碼（讀檔）， 3、修複技能存在問題（類似更新打怪獸） 4、合并到master，送出代碼（完美通關） 5、重新切換到法寶分支（重新讀檔，繼續通關） master * role_talisman-1.0（法寶分支） role_skill-1.0（技能分支）

本地使用git分支好處： 1、代碼不需要儲存多分，由git替我們管理 2、随時讀檔随時存檔，類似你有無限後悔藥進行操作

應對原情景二： 1、建立分支，定時存檔就可以了。

好處： 1、各個需求代碼互相獨立不影響，測試起來未知影響的因素會減少

因為權限原因，是以我們本地不能使用svn的分支功能，但是用git本地也能很好替代這一因素，可見git在單刀攻堅（本地個人開發）還是挺強大的。

分享一下自己常使用的git指令(其實這些大部分ide都內建了，可以不用手敲)： 1、git拉取svn倉庫： git svn clone <svn的倉庫位址（如 https://<svn倉庫位址>/server/trunk）> 2、git 建立分支 : ① git checkout -b <新的分支名> ②git branch <新的分支名> 3、删除分支git branch -d <分支名> 4、檢測是否有更新類似svn update：git svn rebase 5、更新代碼 git svn fetch 6、git合并分支，類似svn，略 7、git送出到遠端svn倉庫：git svn dcommit