版本控制報告

0、若是你的團隊來了一個新隊員，有一臺全新的機器， 大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？ （在這過程當中，不須要和老隊員作任何交流）

 

回答：沒有，由於咱們作的是一個小的遊戲項目。前期咱們已經搭建了一個統一的框架，團隊成員基於這個框架進行程序編譯，你們默契配合，在定義字段和方法上都是通過前期開會協商，因此若是有新成員加入，咱們會給他講解該項目框架的內容，而後分配任務給他。

 

一、你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？

　場景：  程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候，程序員小飛也要改其中一個文件，快速修復一個問題。怎麼辦？

　一個代碼文件被簽出 (check out) 以後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入麼？

　有幾種設計，各有什麼優缺點？

　例如，簽出文件後，此文件就加鎖，別人沒法簽出；  或者， 全部人均可以自由簽出文件

 

回答： 之前從沒作過版本控制，根據老師推薦，咱們的空天獵項目在coding.net上託管，使用git\push項目相關文件和代碼。

　　文件和代碼是開源的，小組成員之間共享。

 

二、如何看到這個文件和以前版本的差別？ 如何看到代碼修改和工做項 （work item），缺陷修復 （bug fix) 的關係。

   場景： 程序員果凍看到某個文件被修改了，他怎麼看到這個文件在最近的修改究竟改了哪些地方？ （例子）

   場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那麼和這100多行對應的其餘修改在什麼文件中呢？ 這個修改是爲了解決哪些問題而做的呢？ 那些問題有工做項 （work item，issue），或者bug 來跟蹤麼？

 

 

回答： 咱們組經過開會對一些要修改的功能進行協商討論，而後負責該部份內容的成員進行代碼更新。咱們沒有查看過git上代碼修改記錄。

 

 

三、若是某個文件在你簽出以後已經被別人修改，而且簽入了，那麼你在簽入你的修改的時候， 如何合併不一樣的修改（merge)? 你用了什麼工具來幫助你？

 

 

回答：咱們每一個成員負責一部分功能模塊，不會涉及到修改別的成員的代碼，對於別的成員的代碼，咱們會採起覆蓋的形式放入咱們的包中。

 

 

四、你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？

    場景： 程序員果凍要簽入 20 個文件，他一個一個地簽入， 在簽入完5 個 .h 文件以後， 他發現一些 .cpp 文件和最新的版本有衝突，他正在花時間琢磨如何合併... 這時候， 程序員小飛從客戶端同步了全部最新代碼， 開始編譯， 可是編譯不成功 - 由於有不一樣步的 .h 文件和 .cpp 文件！  這時候， 別的程序員也來抱怨一樣的問題，果凍應該怎麼辦？

 

 

回答：咱們到目前爲止尚未遇到過不能簽入的狀況。若是有這種狀況，咱們選擇採起小組討論。

 

 

五、你的PC 上有關於三個功能的修改， 可是都沒有完成，有不少文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在乾淨的環境中修改這個 bug, 併成功地簽入你的修改 --- changelist management。

 

回答：新建一個項目，而後把框架導入，將該bug所涉及到的類導入，而後編寫一個測試類進行測試。

 

六、規範操做和自動化

    你的團隊規定開發者簽入的時候要作這些事情：

    - 運行單元測試，相關的代碼質量測試。

    - 代碼複審 （要有別的員工的名字）

    - 和此次簽入相關的issue 編號， 任務/task， 缺陷/bug 編號，等等， 以備查詢。

    請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入全部信息而後提交麼？  （高級功能， 代碼提交以後， 相關bug 的狀態會改動爲  「fixed」， 而且有連接指向此次簽入。）

 

 

回答： 咱們都是各位成員負責本身獨自模塊，本身修改本身的bug。組長進行後期代碼整合，以及整合項目中所遇到的bug。

 

 

七、如何給你的源代碼創建分支？

    場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 大家怎麼作到的？ 在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？

    場景： 大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。 這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？

 

 

回答：經過小組討論，最後將各成員的功能合併到框架中，對於不須要的功能，負責那部分的成員在提交代碼前進行刪除或者更新。

 

 

八、一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

   場景： 一個重要的軟件歷經幾年，幾個團隊的開發和維護，突然出如今某個條件下崩潰的事故， 程序員果凍通過各類debug手段，發現問題是在某一個文件中有一行代碼彷佛顯然出了問題， 可是這個模塊被不少其餘模塊調用，  這行代碼是何時，爲了什麼目的，通過誰簽入的呢？  若是貿然修改， 會不會致使其餘問題呢？  怎麼辦？

 

 

回答：代碼修改完以後從新git上去都有具體的時間。修改的目的會在備註中體現出來，修改者會在系統上顯示出來。

 

 

九、如何給一個系統的全部源文件都打上標籤，這樣別人能夠同步全部有這個標籤的文件版本？

   代碼天天都在變， 有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就能夠同步這個版本， 咱們若是須要發佈，也是從這個版本開始。  那麼如何標記這個 Last Known Good 版本呢？

 

 

回答：項目成員將本身負責的模塊git到遠程分支提交給組長，以組長整合後最穩定的版本進行發佈。

 

 

十、你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？ 修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？

    在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？

    在程序員提交簽入以後，服務器上是否有自動測試程序， 完成編譯，測試，若是成功，就簽入，不然，就取消簽入？

    團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

 

 

回答：咱們只在編程過程當中對代碼進行了調試並無作過專業的項目測試。

 

 

十一、分析比較各類軟件構建環境：

 

 

回答：目前只使用過coding.net進行版本控制，其它軟件未使用過，暫不做評價。