版本控制報告

時間 2019-11-10

標籤版本控制報告简体版

原文原文鏈接

此做業要求參見:https://edu.cnblogs.com/campus/nenu/2019fall/homework/9918git

1、小組狀況程序員

隊名：扛把子服務器

組長：孫曉宇微信

組員：宋曉麗梁夢瑤韓昊劉信鵬app

coding.net地址：https://e.coding.net/PSP_help/PSPHelper.git工具

1、回答問題

問題
　　0. 在吹牛以前，先回答這個問題：若是你的團隊來了一個新隊員，有一臺全新的機器，大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？
　　回答：對於咱們組新來的成員，他只須要先註冊一個coding.net帳戶，按照提示填寫用戶名以及郵箱，由咱們的管理員將該成員添加到咱們的項目中，這時該成員能夠在咱們的代碼倉庫中查看克隆項目代碼，新成員將代碼下載到本地後能夠對代碼進行修改而後從新提交到coding.net上。
　　一、你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？
　　回答：源代碼控制在coding.net上，採用git的方式進行控制。使用的win 7系統。文件沒有設置鎖定，團隊內的全部人均可以將文件下載到本地進行修改而後從新提交。
　　二、如何看到這個文件和以前版本的差別？如何看到代碼修改和工做項（work item），缺陷修復（bug fix) 的關係。單元測試

　　回答：在coding.net中點擊commit便可查看文件的修改時間以及修改內容。或者經過查看coding.net裏的提交歷史來查看。測試

在Excel裏面對代碼修改工做項和缺陷修復進行記錄，在天天的例會中你們對近期修復的Bug和功能進行彙報。操作系統

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

　　回答：在coding.net提出合併請求，將先後修改的文件進行合併，最終由管理員批准合併。或者可使用TortoiseGit工具，使用git merge命令進行合併。咱們小組在進行文件修改以前會在微信羣裏提早聲明本身所作的工做，因此目前還未出現此種狀況。

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

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

　　回答：在簽入以前先對處理有衝突的文件進行對比。在簽入的時候首先把衝突文件更新下來，將文件與本地本身要簽入的文件進行合併，最後再簽入。

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

　　回答：Git爲咱們提供了一種相似於操做系統裏的保存現場的指令，那就是stash。它能夠把當前工做現場"儲藏"起來，等之後恢復現場後繼續工做。工做區會乾淨，咱們這時候能夠在一個乾淨的環境中修復緊急的bug並提交，簽入，在push後，再使用git stash apply 或者 git stash pop來將保存起來的內容取出來。

6. 規範操做和自動化你的團隊規定開發者簽入的時候要作這些事情：運行單元測試，相關的代碼質量測試代碼複審（要有別的員工的名字）和此次簽入相關的issue 編號，任務/task，缺陷/bug 編號，等等，以備查詢。請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入全部信息而後提交麼？（高級功能，代碼提交以後，相關bug 的狀態會改動爲「fixed」，而且有連接指向此次簽入。）

回答：沒有
7. 如何給你的源代碼創建分支？
場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改，同時，主要的分支還保持原來的計劃開發。大家怎麼作到的？在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？
場景：大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？
回答：對於場景一，創建正式版本和演示版本兩個倉庫，將正式版本的內容克隆到演示版本，在演示版本進行修改。演示後，須要修改的分支在正式版本里修改合併。

對於場景二，進行版本備份。

8. 一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的（解決了哪一個任務，或者哪一個bug）？
場景：一個重要的軟件歷經幾年，幾個團隊的開發和維護，突然出如今某個條件下崩潰的事故，程序員果凍通過各類debug手段，發現問題是在某一個文件中有一行代碼彷佛顯然出了問題，可是這個模塊被不少其餘模塊調用，這行代碼是何時，爲了什麼目的，通過誰簽入的呢？若是貿然修改，會不會致使其餘問題呢？怎麼辦？
回答：在源文件的文檔裏作好標註。

9. 如何給一個系統的全部源文件都打上標籤，這樣別人能夠同步全部有這個標籤的文件版本？
代碼天天都在變，有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本）版本，這樣新員工就能夠同步這個版本，咱們若是須要發佈，也是從這個版本開始。那麼如何標記這個 Last Known Good 版本呢？
回答：在最第一版本就創建分支，須要發佈時，從最後一個版本導出。
10. 你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？在程序員提交簽入以後，服務器上是否有自動測試程序，完成編譯，測試，若是成功，就簽入，不然，就取消簽入？團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊。
回答：本小組尚未進行單元測試和其餘測試。

11.分析比較各類軟件構建環境：

回答：coding.net很好用，能很好的作到版本控制，且能公共訪問。