很多產品經理可能一直以來有這樣一個疑問，這么多程序猿是怎么在一起擼代碼的??？

• 方法一：每個人都只寫一個獨立的模塊，堅決不和其他程序猿有交集。（當然，這是活在夢里的想法）
• 方法二：一個程序猿改某個代碼文件的時候其他也需要改動這個文件的程序猿先一邊涼快去，等改完了再上。（聽起來有點對代碼進行排隊輪x的意思啊…）
• 方法三：每個程序猿都按照自己的節奏改代碼，最后把修改合到一起。

聽起來，第三種方法比較靠譜，可是我們還需要依靠一個強大的文件版本管理工具才可以實現哦，這個就是svn。在開始協同擼代碼前，需要在一個公共的主機上搭建svn的服務器，然后如同大廈奠基般需要創建一個svn的目錄，自此，所有程序猿寫的代碼都需要提交到這個svn的目錄上面，同時，所有程序員的代碼修改都要以svn服務器上的代碼為基準。

程序猿在svn上擼代碼時有三個重要操作：更新，編輯沖突，提交。首先程序猿將服務器上的最新代碼更新到本地，然后以此代碼為基準在本地開始進行自己的修改，當自己修改的比較滿意后，會想要將這些本地的修改提交到服務器上，但是由于修改的這段時間，別的程序猿也可能提交了一些代碼，所以需要再次更新一下，看看這段時間別人修改的代碼和自己修改的部分有沒有沖突，這里svn提供了差異比對的功能，如果有相同部分的代碼被修改了，svn就會在更新的時候給出提示，需要程序猿對這些代碼修改沖突的地方進行檢查并再次修改保證沒有沖突后，才可以提交代碼。（代碼提交高峰期可能出現一提交就沖突，剛修改完沖突，一提交又沖突，這個才郁悶?。?/p>

有的程序猿比較懶，會跳過更新，編輯沖突，直接進行提交，如果運氣好，提交的文件在這段時間別人都沒有修改過，那么就沒有沖突，可以提交成功。但是如果提交的時候svn進行比對發現有文件被別人修改過了，這個時候會強制提醒程序猿走一次更新，編輯沖突的流程。一旦提交成功，svn服務器便會詳細記錄此次提交，并遞增的分配一個版本號。

這里看到，svn有兩個重要的功能，文件提交記錄和文件修改比對。

程序猿們在協同編碼的時候也會發生一些有趣的事情。一個人寫代碼會有bug，幾個人同時寫代碼那就更容易出bug了，這樣就會產生bug糾紛，就好比程序代碼被輪x了，懷孕了，現在要找父親了，可父親是誰呢？被列為嫌疑犯的程序猿肯定都不希望孩子是自己的，不免會互相爭論一番。傳統解決方法就是慢慢調試，找到產生bug的相關代碼，然后讓寫bug的程序猿去修復。但是讓誰去調試bug呢，畢竟耗時又耗力？有人愿意擔當還好，如果都覺得bug不是自己的不愿意去查bug，就又會陷入僵持了。這個時候svn就派上用場了：進行代碼回退。svn服務器因為詳細記錄了每次提交，所以它可以完整的回退到任意一個版本上，那么就可以不斷向前回退提交，然后運行程序，就可以找到究竟是哪次提交產生了這個bug，從而確認是哪個程序猿搞出來的bug。

同時根據這個理論，產生了bug追責究極大法-svn二分法，據說被此法追責到的程序猿能繞地球一圈。怎么操作呢？例如回退到版本號100上沒有這個bug，回退到版本號200上有這個bug，那么就回退到版本號150上看看有沒有這個bug，如果有就繼續查版本號125，沒有就查版本號175，以此類推，不斷縮小追查區間，最終一定能確定到某一個版本號對應提交產生了這個bug，只要看看這個版本是誰提交的可以知道是誰的bug了。（當然svn的功能可不僅僅是這些哦，有興趣的可以詳細把玩一下）

古代妃子侍寢的時候都會有太監記錄，這樣日后懷孕了也可以推斷出是不是皇帝的。

歷史總是驚人的相似…

#專欄作家#

給產品經理講技術，微信公眾號（pm_teacher），人人都是產品經理專欄作家。資深程序猿，專注客戶端開發若干年，對前端、后臺技術略懂，熱衷于對新的科技領域的探索。

本文原創發布于人人都是產品經理，未經許可，不得轉載。