0、如果你的團隊來了一個新隊員，有一台全新的機器， 你們是否有一個文檔，隻要設定了相應的權限，她就可以根據文檔，從頭開始搭建環境，并成功地把最新、最穩定版本的軟體編譯出來，并運作必要的單元測試？ （在這過程中，不需要和老隊員做任何交流）
回答：沒有，因為我們做的是一個小的遊戲項目。前期我們已經搭建了一個統一的架構，團隊成員基于這個架構進行程式編譯，大家默契配合，在定義字段和方法上都是經過前期開會協商，是以如果有新成員加入，我們會給他講解該項目架構的内容，然後配置設定任務給他。
1、你的團隊的源代碼控制在哪裡？用的是什麼系統？如何處理檔案的鎖定問題？
場景： 程式員果凍正在對幾個檔案進行修改，實作一個大的功能， 這時候，程式員小飛也要改其中一個檔案，快速修複一個問題。怎麼辦？
一個代碼檔案被簽出 (check out) 之後，另一個團隊成員可以簽出這個檔案，并修改，然後簽入麼？
有幾種設計，各有什麼優缺點？
例如，簽出檔案後，此檔案就加鎖，别人無法簽出； 或者， 所有人都可以自由簽出檔案
回答： 以前從沒做過版本控制，根據老師推薦，我們的空天獵項目在coding.net上托管，使用git\push項目相關檔案和代碼。
檔案和代碼是開源的，小組成員之間共享。
2、如何看到這個檔案和之前版本的差異？ 如何看到代碼修改和工作項 （work item），缺陷修複 （bug fix) 的關系。
場景： 程式員果凍看到某個檔案被修改了，他怎麼看到這個檔案在最近的修改究竟改了哪些地方？ （例子）
場景： 程式員果凍看到某個檔案在最新版本被改動了100 多行， 那麼和這100多行對應的其他修改在什麼檔案中呢？ 這個修改是為了解決哪些問題而作的呢？ 那些問題有工作項 （work item，issue），或者bug 來跟蹤麼？
回答： 我們組通過開會對一些要修改的功能進行協商讨論，然後負責該部分内容的成員進行代碼更新。我們沒有檢視過git上代碼修改記錄。
3、如果某個檔案在你簽出之後已經被别人修改，并且簽入了，那麼你在簽入你的修改的時候， 如何合并不同的修改（merge)? 你用了什麼工具來幫助你？
回答：我們每個成員負責一部分功能子產品，不會涉及到修改别的成員的代碼，對于别的成員的代碼，我們會采取覆寫的形式放入我們的包中。
4、你有20個檔案都是關于同一個功能的修改，你要如何保證這些檔案都同時簽入成功（修改的原子性），或者同時簽入不成功？
場景： 程式員果凍要簽入 20 個檔案，他一個一個地簽入， 在簽入完5 個 .h 檔案之後， 他發現一些 .cpp 檔案和最新的版本有沖突，他正在花時間琢磨如何合并... 這時候， 程式員小飛從用戶端同步了所有最新代碼， 開始編譯， 但是編譯不成功 - 因為有不同步的 .h 檔案和 .cpp 檔案！ 這時候， 别的程式員也來抱怨同樣的問題，果凍應該怎麼辦？
回答：我們到目前為止還沒有遇到過不能簽入的情況。如果有這種情況，我們選擇采取小組讨論。
5、你的PC 上有關于三個功能的修改， 但是都沒有完成，有很多檔案處于半完工的狀态，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在幹淨的環境中修改這個 bug, 并成功地簽入你的修改 --- changelist management。
回答：建立一個項目，然後把架構導入，将該bug所涉及到的類導入，然後編寫一個測試類進行測試。
6、規範操作和自動化
你的團隊規定開發者簽入的時候要做這些事情：
- 運作單元測試，相關的代碼品質測試。
- 代碼複審 （要有别的員工的名字）
- 和這次簽入相關的issue 編号， 任務/task， 缺陷/bug 編号，等等， 以備查詢。
請問你的團隊有這樣的自動化工具讓開發者友善地一次性填入所有資訊然後送出麼？ （進階功能， 代碼送出之後， 相關bug 的狀态會改動為 “fixed”， 并且有連結指向這次簽入。）
回答： 我們都是各位成員負責自己獨自子產品，自己修改自己的bug。組長進行後期代碼整合，以及整合項目中所遇到的bug。
7、如何給你的源代碼建立分支？
場景：你們需要做一個示範，是以在示範版本的分支中對各處的代碼做了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 你們怎麼做到的？ 在示範之後，示範版本的有些修改應該合并到主分支中，有些則不用，你們是怎麼做到的？
場景： 你們的軟體釋出了，有很多使用者，一天，一個使用者報告了一個問題，但是他們是用某個老版本，而且沒有條件更新到最新版本。 這時候，你如何在本地建構一個老版本的軟體，并試圖重制那個問題？
回答：通過小組讨論，最後将各成員的功能合并到架構中，對于不需要的功能，負責那部分的成員在送出代碼前進行删除或者更新。
8、一個源檔案，如何知道它的每一行都是什麼時候簽入的，為了什麼目的簽入的 （解決了哪個任務，或者哪個bug）？
場景： 一個重要的軟體曆經幾年，幾個團隊的開發和維護，忽然出現在某個條件下崩潰的事故， 程式員果凍經過各種debug手段，發現問題是在某一個檔案中有一行代碼似乎顯然出了問題， 但是這個子產品被很多其他子產品調用， 這行代碼是什麼時候，為了什麼目的，經過誰簽入的呢？ 如果貿然修改， 會不會導緻其他問題呢？ 怎麼辦？
回答：代碼修改完之後重新git上去都有具體的時間。修改的目的會在備注中展現出來，修改者會在系統上顯示出來。
9、如何給一個系統的所有源檔案都打上标簽，這樣别人可以同步所有有這個标簽的檔案版本？
代碼每天都在變， 有時品質變好，有時變差，我們需要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就可以同步這個版本， 我們如果需要釋出，也是從這個版本開始。 那麼如何标記這個 Last Known Good 版本呢？
回答：項目成員将自己負責的子產品git到遠端分支送出給組長，以組長整合後最穩定的版本進行釋出。
10、你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的麼？ 修改源代碼會確定相應的測試也更新麼？你的團隊是否能部署自動建構的任務？
在簽入之前，程式員能否自動在自己的機器上運作自動測試，以保證本地修改不會影響整個軟體的品質？
在程式員送出簽入之後，伺服器上是否有自動測試程式， 完成編譯，測試，如果成功，就簽入，否則，就取消簽入？
團隊是否配置了伺服器，它自動同步所有檔案，自動建構，自動運作相關的單元測試，碰到錯誤能自動發郵件給團隊
回答：我們隻在程式設計過程中對代碼進行了調試并沒有做過專業的項目測試。
11、分析比較各種軟體建構環境：
回答：目前隻使用過coding.net進行版本控制，其它軟體未使用過，暫不作評價。