做業題目： 團隊源代碼管理

做業題目： 團隊源代碼管理

 

參考如下網站中對團隊項目源代碼管理的十個問題的解析，根據本身項目的實際狀況，給出十個問題的答案，並整理成團隊博客發表在組長的我的博客上。

 

•       http://www.cnblogs.com/xinz/p/5044037.html 

 

一、你的團隊的源代碼控制在哪裏？用的是什麼系統？

咱們的項目在github上託管，經過GitHub的客戶端就能夠進行各類源代碼控制，好比顯示與查看代碼更改內容，更改歷史，以及代碼回滾等功能。針對這種多人多任務的開發模式，咱們認爲git是再好不過的選擇，因而咱們打算採用這種方式。

二、一個代碼文件被簽出以後，另外一我的能夠簽出這個文件，並修改麼？有幾種設計，各有什麼優缺點？

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

針對這個場景，首先要劃分優先級，若是程序員a要修復的問題須要立刻馬上發佈補丁，那麼，程序員a應該直接簽入修改的文件，發佈完之後，程序員b先備份本身寫好的文件，而後把程序員a簽入的文件更新到本地，而後在本地將本身備份的文件和更新的文件進行合併便可。

簽出文件後，此文件就加鎖，別人沒法簽出：

這種狀況，能夠保證每一個人獲取的文件版本是最新的，也不會產生修改衝突。可是這種方式花費的時間相對要長一些，由於其餘人要等簽出這個文件的人簽入完畢之後才能簽出下來進行修改。

GitHub文件的鎖定：

GitHub是不支持對同一個文件進行不一樣的簽入的，因此兩我的不能修改同一個文件，而這一點的保證是經過咱們的分工實現的，由於人比較少，因此每一個人負責的部分分的比較開，並且你們比較容易交流，同時修改同一個文件的狀況會被避免掉。

全部人均可以自由簽出文件：

因爲現階段的開發規模比較小，因而爲了最大化效率，咱們沒有對文件遷入遷出進行過多的限制。將文件在遷入遷出時加鎖，顯然能夠保證源代碼修改的同步性，減小沒必要要的衝突和錯誤，全部人均可以自由簽出文件，這種狀況你們各自修改本身須要修改的模塊，可是到合併代碼的時候，須要人工合併，這種方式風險會大一些，特別是同一我的修改一個文件涉及到相同函數的修改。

 

 

三、如何看到這個文件和以前版本的差別？

在git管理中， 使用git diff便可看到文件和以前版本的差別。
 git diff：是查看working tree（工做目錄）與index file（暫存區）的差異的。
 git diff --cached：是查看index file（暫存區）與commit（本地倉庫）的差異的。
 git diff HEAD：是查看working tree（工做目錄）和commit（本地倉庫）的差異的。
在git裏，這三個概念是很重要的，其中 git add的一個功能是將修改從工做目錄添加到index file，commit的工能就是從index file的修改添加到 commit。

四、若是某個文件在你簽出以後已經被別人修改，那麼你如何合併不一樣的修改（merge)?

使用GitBash工具更新本地倉庫，有衝突時對比解決衝突，而後簽入代碼

 

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

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

答：在實際開發中確實會遇到這樣的問題，然而在Git中，全部在本地倉庫中修改的文件都要統一通過commit爲新的本地版本後，再push至遠程分支。這就保障了本地修改提交的原子性，同時git服務器遠程提供的修改操做也具備原子性。這樣就保障了總體修改的原子性。

 

六、你的PC 上有關於三個bug 的修改， 可是都沒有完成，這時你要緊急修改第四個bug，如何把本地修改放一邊，保證在乾淨的環境中修改第四個bug, 並簽入修改？

答：針對這個問題，最笨可是直接的方法就是將遠程工程clone到本地，而後在另外一個git倉庫中修改bug。

然而，若前期用到了分支，即自己正在進行的大範圍修改是在一個分支中進行的，那麼能夠新建一個branch，先將當前的branch放一邊，在新的branch中reset到前一個版本，再進行修改和commit。

 

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

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

答：使用github直接在上面進行打分支操做。

 

八、一個源文件，如何知道它的每一行都是何時簽入的？

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

答：（1）git中有修改先後的對比，根據顏色咱們能夠找到修改的部分。是哪位成員在哪一個時間提交的。此時電話諮詢該同窗。       

（2）用github的管理功能。      

（3）對於團隊來說每一次的任務都會被提早打上標籤，並且在最後的簽入的時候會有commit的記錄保留，github上面有每一次的每個人的提交的記錄，對應着很是容易找到相關負責人。 

 

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

 咱們須要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就能夠同步這個版本， 咱們若是須要發佈，也是從這個版本開始。 那麼如何標記這個 Last Known Good 版本呢？ 
   在github上每次提交的時候將本身所寫的內容標記好是什麼。在後面同步的時候就可以清楚的看到。

 

十、你的團隊是否能部署自動構建的任務 （自動同步全部文件，自動構建，自動運行單元測試，碰到錯誤能自動發郵件給團隊）

答：配置了服務器，一開始使用的是Travis-CI來自動集成測試，可是因爲網絡因素，Travis-CI登陸很慢，因此最後決意採用了drone.io來進行自動化的單元測試，每次測試都會自動按照預約的腳本運行單元測試，單元測試經過之後能夠在Github的ReadMe裏體現出來。

是這樣的標誌：

 

 

點開build passing的示例，咱們能夠看到在drone.io中咱們部署的自動化測試：　

 

　

每一次commit都會觸發自動化測試，在部署成功後（只針對master分支），已經test了38次。

 

 

 在Setting中也能夠看到，咱們在build出錯時，會自動通知個人郵箱（ll58741@163.com)