團隊博客做業——團隊源代碼管理

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

首先，咱們選擇git管理代碼；

咱們須要進行待修復的問題進行評估，如果待修復的問題須要當即發佈補丁，那麼則須要對方直接簽入修改文件，修改完成後，發佈同時須要備份本身編寫的文件，而後把對方的文件更新到本地，以後在本地將本身備份的文件和更新後的文檔進行併入【merge】。

 

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

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

狀況	狀況描述	優勢	缺點
①	簽出文件後，此文件就加鎖，別人沒法簽出	能夠保證每個人獲取的文件版本都是最新的，避免了修改衝突的產生。	花費時間較長
②	任何人均可以自由簽出	每一個人均可以各自修改本身須要修改的模塊。	在代碼合併時須要進行人工合併；同時風險略高。

 

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

以github爲例，進入項目後便可查看項目的編輯記錄，以下圖：

 

 

另外，不少開發工具自己也具有show history功能，

 在github上，在code頁上，點擊下圖標誌，進入commits查看記錄

 

 

進入commits後，以下圖

 

 

從上圖中能夠看到，commits中也記錄了改動的緣由，如刪除、更新；對於bug問題，在issue窗口咱們能夠進一步瞭解，以下圖：

 

在每一次提交時，咱們均可以對提交的項目進行描述，方便以後查看。

 

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

Git能夠方便的對不一樣的簡單修改進行合併，同時，對於存在邏輯衝突的代碼則會給出提示，提醒用戶進行手動修改；

另外，Beyond Compare 4能夠處理合並修改的問題

下載地址：http://www.scootersoftware.com/download.php

 

 

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

在簽入前，必定要對比處理存在衝突的文件；在git中，全部本地倉庫中的文件都要經過commit保證爲最新本地版本，避免了上述狀況的發生。

統一採用git將本地代碼上傳至github。在每一次簽入代碼以前都須要通過測試，測試無誤後纔會簽入，這就在必定程度上保證了同一個功能的相關文件都被正確修改了，而後這時再一塊兒簽入。假如測試有遺漏，在以後的階段仍是能夠查看到相應記錄的，而後再進行相應修改。因爲團隊成員較少，能夠經過彼此的交流避免此類問題，當咱們須要進行一個功能的修改時，會在微信上說明。而在經過git push 將本地代碼上傳以前，均須要將本地的改變提交至本地倉庫，commit操做會生成一個commit對象，因此Push時只是將此次commit對象提交至遠程分支。而git會隨時保證數據的完整性，一旦上傳過程當中出現問題（斷網），會撤銷掉以前的上傳記錄。

經過查看提交記錄驗證，文件是否同時提交成功，若沒法同時成功提交，則使用git reset命令撤回提交記錄。

 

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

建立新的分支，切換到該分支，修改bug後，提交該分支。經過git pull將遠程分支代碼拉到本地進行BUG修改，以後在同以前的分支進行合併，在經過git push上傳至遠程分支。

當把一個功能修改完成並測試完成後，上傳至github並更新本地的備份文件。保證本地保存有一個最新的無bug的工程文件，這樣既能夠方便緊急進行修改，也能處理修改過程當中發現這條路行不通，換個方式解決問題的狀況。

 

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

使用git branch新建本地分支，切換分支後，push到遠程倉庫。創建分支利用git branch 分支名 操做，跳轉到相應分支用git check out 操做，分支合併用git merge 操做，在確認了修改之後，進行git commit 操做提交。

（1）建立dev分支，而後切換到dev分支：

 

 （2）用git branch命令查看當前分支：

 

 （3）在dev分支上正常工做，好比對file.java作個修改:

 

dev分支的工做完成後，就可使用git checkout master切換回master分支。

 如下是關於分支的命令：

查看分支：git branch

建立分支：git branch <name>

切換分支：git checkout <name>

建立+切換分支：git checkout -b <name>

合併某分支到當前分支：git merge <name>

刪除分支：git branch -d <name>

 

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

（1）在GitHub會自動記錄每行代碼的簽入時間和整個簽入時的加入的標註，所以經過查看記錄就能夠知道上述問題。

git blame [filename] -L 開始行號,結束行號。格式： commit ID | 代碼提交做者 | 提交時間 | 代碼位於文件中的行數 | 實際代碼

 cd 到該文件所在目錄，使用git log查看提交記錄，而後可使用git show 命令查看具體的修改詳情了。代碼：git show <git提交版本號> <文件名>

（2）採用在修改的代碼後添加註釋，說明是什麼時候由哪一個組員進行修改的。

 

如下是使用git log查看的命令：

1. git log 查看提交歷史記錄。

2. git log --oneline 或者 git log --pretty=oneline 以精簡模式顯示。

3. git log --graph 以圖形模式顯示。

4. git log --stat 顯示文件更改列表。

5. git log --author= 'name' 顯示某個做者的日誌。

6. git log -p filepath 查看某個文件的詳細修改。

7. git log -L start,end:filepath 查看某個文件某幾行範圍內的修改記錄。

8. git log --stat commitId 或者 git show --stat commitId 查看某一次提交的文件修改列表。

 

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

在git 的時候，標籤是用在有重大更新或者改動的時候，能夠用版本號來標識，例如v1.0。當編寫完最終版本後，能夠在版本後的加入後綴-Last來標識。

命令git tag <tagname>用於新建一個標籤，默認爲HEAD，也能夠指定一個commit id；

 

命令git tag -a <tagname> -m "..."能夠指定標籤信息；

 

命令git tag能夠查看全部標籤。

 

也能夠用git show <tag name> 查看標籤信息。

 

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

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

咱們團隊並無構建自動測試腳本。組員會將本身的代碼進行單元測試後將結果發在微信羣中。團隊的部分代碼上傳至GitHub的團隊倉庫中，遇到錯誤時多在微信羣中討論並解決問題。