源碼管理的10個問題
1. 你的團隊的源代碼控制在哪裏？用的是什麽系統？如何處理文件的鎖定問題？
場景： 程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候，程序員小飛也要改其中一個文件，快速修復一個問題。怎麽辦？
一個代碼文件被簽出 (check out) 之後，另一個團隊成員可以簽出這個文件，並修改，然後簽入麽？
有幾種設計，各有什麽優缺點？
例如，簽出文件後，此文件就加鎖，別人無法簽出； 或者， 所有人都可以自由簽出文件
回答問題：我們團隊的代碼在github上，用的是windows系統。我們團隊的在處理文件的鎖定問題沒有加鎖，我們的項目比不上大型企業的項目，所以沒有對文件遷入遷出進行過多的限制。將文件在遷入遷出時加鎖，顯然可以保證源代碼修改的同步性，減少不必要的沖突和錯誤，但是這樣的缺點是顯而易見的，由於缺乏了並行性，項目開發的效率就被極大地降低了，以我們小組現在的項目規模就不需要加鎖。
回答場景：主分支master,若要實現一個大的功能，可以在當前master分支開一個新的分支用戶對文件進行改寫。下一個人也開在當前master分支開一個分支新的用戶分支進行bug的修復，修復完成之後與master進行合並，完成了功能的實現之後再與master分支進行合並。
2. 如何看到這個文件和之前版本的差異？ 如何看到代碼修改和工作項 （work item），缺陷修復 （bug fix) 的關系。
場景： 程序員果凍看到某個文件被修改了，他怎麽看到這個文件在最近的修改究竟改了哪些地方？ （例子）
場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那麽和這100多行對應的其他修改在什麽文件中呢？ 這個修改是為了解決哪些問題而作的呢？ 那些問題有工作項 （work item，issue），或者bug 來跟蹤麽？
git pull進行更新後，可以看到本地的版本和最新的版本之間的不同之處。
同時，在本地上傳自己的文件到分支之後也可以查看自己或者是別人上傳的文件在以前的版本的基礎上，修改了哪些地方。
點開項目的commit的記錄，點擊相應的SHA版本哈希值之後可以進入到如下的頁面
我們在上面圖片裏面可以看到的是”+”標註的是在原文件的基礎上增加的代碼的記錄，”-“標註的是在原文件的基礎上刪掉的代碼的部分，顏色顯示也不同。
3. 如果某個文件在你簽出之後已經被別人修改，並且簽入了，那麽你在簽入你的修改的時候， 如何合並不同的修改（merge)? 你用了什麽工具來幫助你？
如果文件被隊員修改了並提交，你也修改並要提交的時候，在IDEA上將隊員修改的地方pull下來，然後手動解決沖突
這個圖的左邊是你現在文件的內容，右邊是隊員提交當遠程倉庫的內容，然後手動進行沖突的解決，最後再提交到遠程的倉庫
4. 你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？
場景： 程序員果凍要簽入 20 個文件，他一個一個地簽入， 在簽入完5 個 .h 文件之後， 他發現一些 .cpp 文件和最新的版本有沖突，他正在花時間琢磨如何合並... 這時候， 程序員小飛從客戶端同步了所有最新代碼， 開始編譯， 但是編譯不成功 - 因為有不同步的 .h 文件和 .cpp 文件！ 這時候， 別的程序員也來抱怨同樣的問題，果凍應該怎麽辦？
用IDEA的資源庫同步的功能，這個功能可以顯示有沖突的文件（用紅色標註），在簽入的時候，先把沖突文件更新下來，與本地自己要簽入的文件進行一輪merge，參考第三題的方式，然後再把20個文件一起簽入即可。
5. 你的PC 上有關於三個功能的修改， 但是都沒有完成，有很多文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在幹凈的環境中修改這個 bug, 並成功地簽入你的修改 --- changelist management。
在當前master分支開一個新的分支brach對文件進行改寫。當前master分支開一個分支bug進行bug的修復，修復完成之後與master進行合並，完成了功能的實現的brach分支之後再與master分支進行合並。
6. 規範操作和自動化
你的團隊規定開發者簽入的時候要做這些事情：
- 運行單元測試，相關的代碼質量測試。
- 代碼復審 （要有別的員工的名字）
- 和這次簽入相關的issue 編號， 任務/task， 缺陷/bug 編號，等等， 以備查詢。
請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入所有信息然後提交麽？ （高級功能， 代碼提交之後， 相關bug 的狀態會改動為 “fixed”， 並且有鏈接指向這次簽入。）
例子。
沒有
7. 如何給你的源代碼建立分支？
場景：你們需要做一個演示，所以在演示版本的分支中對各處的代碼做了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 你們怎麽做到的？ 在演示之後，演示版本的有些修改應該合並到主分支中，有些則不用，你們是怎麽做到的？
場景： 你們的軟件發布了，有很多用戶，一天，一個用戶報告了一個問題，但是他們是用某個老版本，而且沒有條件更新到最新版本。 這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？
在master上建立分支，每一段修改都進行交付。將不需要的修改的地方刪除。
在master上建立分支，找歷史交付版本，將其下載到本地，需要哪個版本都可以進行安裝，繼而重現用戶報告的問題。
8. 一個源文件，如何知道它的每一行都是什麽時候簽入的，為了什麽目的簽入的 （解決了哪個任務，或者哪個bug）？
場景： 一個重要的軟件歷經幾年，幾個團隊的開發和維護，忽然出現在某個條件下崩潰的事故， 程序員果凍經過各種debug手段，發現問題是在某一個文件中有一行代碼似乎顯然出了問題， 但是這個模塊被很多其他模塊調用， 這行代碼是什麽時候，為了什麽目的，經過誰簽入的呢？ 如果貿然修改， 會不會導致其他問題呢？ 怎麽辦？
在GitHub上每次提交，都會留下commit記錄。至於“追責”問題，github上面有每一次的每一個人的提交的記錄，對應著非常容易找到相關負責人。在我們團隊包括文檔的提交、代碼都是由一個人負責上傳，為了防止git代碼提交沖突問題，小組就將上傳任務分配給一個人負責。這樣方便管理和操作。
9. 如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？
代碼每天都在變， 有時質量變好，有時變差，我們需要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就可以同步這個版本， 我們如果需要發布，也是從這個版本開始。 那麽如何標記這個 Last Known Good 版本呢？
在github上每次就該並提交的時候將自己所寫的內容標記好，是什麽。在後同步的時候就能夠清晰。
10. 你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的麽？ 修改源代碼會確保相應的測試也更新麽？你的團隊是否能部署自動構建的任務？
在簽入之前，程序員能否自動在自己的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？
在程序員提交簽入之後，服務器上是否有自動測試程序， 完成編譯，測試，如果成功，就簽入，否則，就取消簽入？
團隊是否配置了服務器，它自動同步所有文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊。
此階段均在本地測試
源碼管理的10個問題