版本控制報告git
0.在吹牛以前,先回答這個問題: 若是你的團隊來了一個新隊員,有一臺全新的機器, 大家是否有一個文檔,只要設置了相應的權限,她就能夠根據文檔,從頭開始搭建環境,併成功地把最新、最穩定版本的軟件編譯出來,並運行必要的單元測試?
答:沒有,這些文檔寫在博客園中,只要新來的人有語言閱讀的基礎能力,就能夠經過這些文檔瞭解項目的進展以及將要作什麼。可是進行單元測試這部分就不肯定了,得須要根據同窗的能力來決定。
1.你的團隊的源代碼控制在哪裏?用的是什麼系統?如何處理文件的鎖定問題?
答:在組長的電腦裏和github上。用的是windows系統。目前沒有遇到這個問題,你們每人完成一部分功能,所以沒有發生過文件鎖定的衝突問題。
2.如何看到這個文件和以前版本的差別? 如何看到代碼修改和工做項 (work item),缺陷修復 (bug fix) 的關係。
答:每次修改都有不一樣,這就是目前文件與以前文件的版本差別。閱讀全部代碼而且比較2份文件的不一樣就能夠看到修改的地方。不過在git上能夠直接顯示不一樣的代碼區域。
3.若是某個文件在你簽出以後已經被別人修改,而且簽入了,那麼你在簽入你的修改的時候, 如何合併不一樣的修改(merge)? 你用了什麼工具來幫助你?
答:沒有遇到這個狀況。我寫了代碼以後,將所有的文件發給隊友,他們繼續修改。
4.你有20個文件都是關於同一個功能的修改,你要如何保證這些文件都同時簽入成功(修改的原子性),或者同時簽入不成功?
答:先備份,以後仔細的一個個簽入,若不成功則刪除掉新文件,不簽入。
5.你的PC 上有關於三個功能的修改, 可是都沒有完成,有不少文件處於半完工的狀態,這時你要緊急修改一個新的 bug,如何把本地修改放一邊,保證在乾淨的環境中修改這個 bug, 併成功地簽入你的修改 --- changelist management。
答:把當前修改的地方註釋掉,保留入口等基礎狀況,不報錯就行了。以後調整了緊急的bug以後再從新開始寫 。
6.規範操做和自動化
你的團隊規定開發者簽入的時候要作這些事情:
- 運行單元測試,相關的代碼質量測試。
- 代碼複審 (要有別的員工的名字)
- 和此次簽入相關的issue 編號, 任務/task, 缺陷/bug 編號,等等, 以備查詢。
請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入全部信息而後提交麼? (高級功能, 代碼提交以後, 相關bug 的狀態會改動爲 「fixed」, 而且有連接指向此次簽入。)
答:沒有
7.如何給你的源代碼創建分支?
答:使用以前的文件備份看成代碼分支。
8.一個源文件,如何知道它的每一行都是何時簽入的,爲了什麼目的簽入的 (解決了哪一個任務,或者哪一個bug)?
答:目前不知道。也沒有記錄它是何時什麼緣由簽入的。
9.如何給一個系統的全部源文件都打上標籤,這樣別人能夠同步全部有這個標籤的文件版本?
答:使用github保存代碼。
10.你的項目的源代碼和測試這些代碼的單元測試,以及其餘測試腳本都是放在一塊兒的麼? 修改源代碼會確保相應的測試也更新麼?你的團隊是否能部署自動構建的任務?
答:我我的沒有進行單元測試。github