團隊做業-WEEK 14- 團隊源代碼管理

(1) 你的團隊的源代碼控制在哪裏？用的是什麼系統？

 答：咱們團隊的源代碼控制在Git，Git是一款開源的分佈式版本控制工具。用的是Win10系統。

 

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

答：簽出文件後主要有兩種設計：

① 此文件被加鎖，其餘人沒法簽出

優勢：能夠保證每一個人獲取的文件版本是最新的，也不會產生修改衝突。

缺點：這種方式花費的時間相對要長一些，由於其餘人須要要等到其餘人修改完文件後才能簽出來進行本身的修改。

② 不加鎖，全部人能夠自由簽出文件並進行修改

優勢：你們能夠各自修改本身須要修改的模塊。

缺點：合併代碼的時候，會產生衝突，須要人工去修改。特別是幾我的修改一個文件涉及到相同函數的修改。

 

(3) 如何看到這個文件和以前版本的差別？

答：有如下方法看到這個文件和以前版本的差別：

① 查看兩個提交版本id的修改記錄差別

使用$ git diff commit-id1   commit-id2

 

② 查看兩個提交版本id修改了那些文件

使用$ git diff commit-id1 commit-id2 --stat

 

③ 提交日誌顯示每一個版本的提交主題和具體修改的文件名字

使用$ git log --name-only

 

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

答：在Git中，會對有衝突的代碼作出相應的提示(conflict)，屆時進行手動合併就能夠合併不一樣的修改了。

在Github中，能夠經過git log命令來查看歷史提交記錄後進行合併不一樣的修改。

 

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

答：能夠經過git中的commit先將全部本地修改保存到本地版本庫中，再統一push到服務器版本庫中，這樣就保證了修改的原子性。

 

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

答：首先備份在本地一份工程，而後在本地新建一個分支，在新的分支上進行bug的修復，當前分支的內容就被保存在原地。

 

(7) 如何給你的源代碼創建分支？

答：在Github中：① 打分支：有條件地合併分支和主分支

② 新建一個分支，在這個分支上，回滾到用戶所用的版本

 

在Git中：經過git reset --hard + 哈希值：回溯到指定版本

 

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

以Github爲例：執行git blame命令，便可顯示每一行都是何時簽入的，爲了什麼目的簽入的，簽入人是誰。

或者在Github頁面上：

 

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

答：① 在Git上能夠使用打基線（針對項目源碼）的方式，打基線是將每次發佈的版本源碼放到一個文件夾下面，例：此次發佈的是1.1版本，就在版本管理庫(Git)裏面的目錄(tag)下，創建一個名字V1.1的分支，而後把V1.1版本的源碼都放進去。但這樣作的方式維護起來比較麻煩，V1.1發佈之後，若是要改一些臨時修復的緊急bug，還要在tag下的V1.1文件夾中創建一個patch文件夾來放修改bug涉及的源碼文件。

② 在Github上發佈的時候，能夠編輯想要release的文件信息，建立標籤並設置版本號並上傳文件。這樣的話，看提交歷史就能夠很清楚的找到LKG版本，並且也容易回滾。

 

(10) 你的團隊是否能部署自動構建的任務

• （自動同步全部文件，自動構建，自動運行單元測試，碰到錯誤能自動發郵件給團隊）

答：鑑於水平有限，在部署自動構建的任務嘗試不成功後，咱們團隊決定進行手動測試，更新修改源代碼後會自動更新備份，單元測試及其餘測試也會在更新修改源代碼後手動進行，有錯誤會在測試代碼中修改，而後也會更新時間線上傳修改過的代碼，所以沒有部署自動構建的任務。

 

團隊總結：咱們在一點點深刻學習和探索Github和Git代碼管理平臺的過程當中，遇到了一些困難和問題，並花費了很多的時間去解決問題（有問題因水平問題暫沒法解決），這讓咱們發現咱們只是接觸了Github和Git代碼管理平臺的皮毛，仍需繼續努力學習Github和Git代碼管理平臺。