構建之法 -源代碼管理

源代碼管理

在第十四周的團隊博客做業上，王老師讓咱們針對團隊項目源代碼管理提出了是個問題並進行了解析，咱們根據本身的實際狀況，給出了這十個問題的答案，並整理成了團隊博客發佈。

做爲一個程序猿，源碼的管理是一個頭等大事來的，想象一下，修改完成卻發現文件丟失了，該怎麼辦？有了源代碼管理工具，可以幫助咱們查看某個代碼文件的修改內存及歷史修改記錄。

軟件工程中，也有相似腳手架，塔吊這樣的工程系統，工具和流程。 軟件的源代碼管理工具（source code control system），加上構建系統 （build system）, 能保證一個複雜軟件能在多個角色，多個團隊的合做下，按時以合適的質量發佈。 若是你寫一個Hello World 程序， 固然不須要這些工具， 就像你用兒童積木搭房子過家家，你本身高興，但這不是建築工程。在通過（實際不到）一年的學習（入坑），我使用過Gitlab，GitHub，Gitee做爲源代碼管理器

 

源代碼管理的10 個實踐問題：

1.你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？

場景：程序員1正在對幾個文件進行修改，實現一個大的功能，這時候，程序員2也要改其中一個文件，快速修復一個問題，該怎麼辦？

一個代碼文件被簽出後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入嗎？

有幾種設計？各有什麼優缺點？

答：源代碼的控制在github上，當一我的簽出一個文件後，另外一我的不能夠簽出這個文件，這樣的優勢是保證文件不會混亂，若是兩我的修改了同一個地方，就不知道最後採起誰的方法，缺點是可能會影響程序開發的效率，由於若是兩我的同時修改這個文件不一樣的地方便會加快開發的效率。 

2. 如何看到這個文件和以前版本的差別？如何看到代碼修改和工做項（work item），缺陷修復 （bug fix) 的關係。

答：每次push時在commit中的message部分註明修改內容，這樣本次checkin作了什麼改動一目瞭然；也能夠在coding.net代碼詳情中查看具體作了哪些修改。另外咱們小組的開發工具也支持版本控制，可查看具體的修改。

例如：

 

假設場景，例如當某團隊程序員看到某個文件被修改了，而且想要閱讀到這個文件在最近的修改酒精改動了哪些地方，或者說看到某個文件在最新版本被改動了幾百行，那麼這幾百行對應的其餘修改在何處文件中，這些修改所要解決的問題以及工做項，如何找尋到這些bug或是問題來源呢？

一、本團隊發現不少開發工具都有show history（查看歷史）的功能，那麼咱們點擊此功能，就能夠查詢到歷史改動痕跡或者是歷史版本，就像一個時光穿梭機，對於文件的提交歷史和提交修改也能夠輕鬆的閱覽到，例如由咱們安卓開發軟件Android studio咱們就能夠看到有的history查看功能：

二、當咱們打開github的時候，咱們也能夠看到在github網頁版主頁中，當咱們選中咱們的其中一個項目以後，進入code界面，點擊comparing changes，就會看到你的項目的改動

 

三、對於查詢歷史改動在何處的場景問題，基本是經過查看提交時候的comment來肯定此次提交的修改緣由是什麼。Bug和功能列表一般在另一個系統記錄，好比：Excel，在Excel裏面對Bug和功能進行標記（已完成，未完成，進行中），通常開會的時候你們對近期修復的Bug和功能按照這個Excel表的內容一塊兒來過一遍。對於和這個幾百多行的修改一塊兒簽入的其餘修改，在Eclipse+SVN下能夠查看相關修改的文件以及修改緣由：

在某個文件上點擊右鍵：Team->顯示資源歷史紀錄：

也能夠自動關聯bug/issue和每次簽入的修改之間的關係，用戶能夠提交Issue，並把Issue標記爲bug，開發人員提交代碼的時候，加上如下描述信息，對應的Issue就會被Close，fix #+Issue編號，如：fix #1 對應編號爲1的Issue被關閉  

 

 

 

 

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

本團隊想到可使用GitBash工具更新本地倉庫，有衝突時對比解決衝突，而後簽入代碼。又或者備份本地本身開發的一份代碼，先把別人簽入的代碼更新到本地，而後在本地手動合併修改，用的工具是Beyond Compare。 

4.你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功，或者同時簽入不成功？

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

答：在簽入以前，必定要先對比處理有衝突的文件，這樣能夠方便他人使用修改

在簽入的時候，先把衝突文件更新下來，與本地本身要簽入的文件進行一輪合併。再去簽入。

 

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

答：1)在new分支上的時候在命令行輸入：

git stash

或者

git stash save 「修改的信息"。

這樣之後你的代碼就回到本身上一個commit了，直接git stash的話git stash的棧會直接給你一個hash值做爲版本的說明，若是用git stash save 「修改的信息」，git stash的棧會把你填寫的「修改的信息」做爲版本的說明。

2)接下來你回到old分支修改代碼完成，你又再回到new分支，輸入：

git stash pop

或者

git stash list

git stash apply stash@{0}

就能夠回到保存的版本了。git stash pop的做用是將git stash棧中最後一個版本取出來，git stash apply stash@{0}的做用是能夠指定棧中的一個版本

3)經過git stash list能夠看到全部的版本信息：

stash@{0}: On order-master-bugfix: 22222

stash@{1}: On order-master-bugfix: 22222

4)而後你能夠選擇一個你須要的版本執行：

git stash apply stash@{0}

這時候你擱置的代碼就回來了。

六、規範操做和自動化

    你的團隊規定開發者簽入的時候要作這些事情：

    - 運行單元測試，相關的代碼質量測試。

    - 代碼複審 （要有別的員工的名字）

    - 和此次簽入相關的issue 編號， 任務/task， 缺陷/bug 編號，等等， 以備查詢。

    請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入全部信息而後提交麼？  （高級功能， 代碼提交以後， 相關bug 的狀態會改動爲  「fixed」， 而且有連接指向此次簽入。）

答：暫時沒有。

 

8. 一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

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

成員在Gitlab上提交修改過的代碼，都會要求添加備註，好比修改的地方，還有修改的緣由。這樣，當代碼出現問題以後，就能夠很容易的找到當時的修改人，查看緣由，有助於代碼的修改。

下面的commit能夠填寫該項目須要備註的信息，好比能夠編輯 人員/update/時間等信息 方便對項目進行管理

 

8. 一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

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

1)查看分支

git branch    查看本地倉庫

git branch -r 查看遠程倉庫

2)建立分支

git checkout -b feature-A

3)切換分支

    git checkout master 切換到master分支

    git checkout -    切換回上一個分支

4)獲取倉庫代碼

git pull origin master

5)修改代碼提交到feature-A分支上

    git add .    添加文件

    git commit -m 'add branch' 提交代碼

    git push -u origin feature-A 推送至遠程倉庫master之外的分支

6)合併代碼到master分支

   假設分支feature-A已經實現完成，想要將它合併到主幹分支master中。首先切換到master分支

git checkout master

git merge --no-ff feature-A

7)以圖表形式查看分支

git log --graph

也能夠經過可視化工具進行建立分支

 

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

   代碼天天都在變， 有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就能夠同步這個版本， 咱們若是須要發佈，也是從這個版本開始。  那麼如何標記這個 Last Known Good 版本呢？ 

用戶手冊

meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git tag -h usage: git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <tagname> [<head>] or: git tag -d <tagname>... or: git tag -l [-n[<num>]] [--contains <commit>] [--no-contains <commit>] [--points-at <object>] [--format=<format>] [--[no-]merged [<commit>]] [<pattern>...] or: git tag -v [--format=<format>] <tagname>... -l, --list list tag names -n[<n>]               print <n> lines of each tag message -d, --delete delete tags -v, --verify verify tags Tag creation options -a, --annotate annotated tag, needs a message -m, --message <message> tag message -F, --file <file>     read message from file
    -e, --edit force edit of tag message -s, --sign            annotated and GPG-signed tag --cleanup <mode> how to strip spaces and #comments from message -u, --local-user <key-id> use another key to sign the tag -f, --force           replace the tag if exists --create-reflog create a reflog Tag listing options --column[=<style>]    show tag list in columns --contains <commit> print only tags that contain the commit --no-contains <commit> print only tags that don\'t contain the commit
    --merged <commit> print only tags that are merged --no-merged <commit> print only tags that are not merged --sort <key>          field name to sort on --points-at <object>  print only tags of the object
    --format <format>     format to use for the output --color[=<when>] respect format colors -i, --ignore-case     sorting and filtering are case insensitive

列出現有標籤

命令:git tag

參數說明:

-l:接通配符表達式實現篩選

例子:

# 剛開始進入項目，發現沒有標籤,後面會逐一補充 meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git tag

新建標籤

命令:git tag -a v0.1.0 -m 'init'

參數說明:

-a/--annotated:註釋，後接標籤名，不須要引號

-m/--message:信息，後接註釋說明文字，需帶引號

結果:

meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git tag -a v0.1.0 -m 'init' meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git tag v0.1.0 meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git show v0.1.0 tag v0.1.0 Tagger: unknown <545641826@qq.com> Date: Mon May 27 04:58:08 2019 +0800 init commit b30d3b3e00a93e43d8219ca584b4ce380c6f6be8 (HEAD -> master, tag: v0.1.0, origin/master, origin/HEAD) Author: ylin <545641826@qq.com> Date: Tue Dec 11 11:46:10 2018 +0800 first commit diff --git a/.gitignore b/.gitignore index 871bb87..8fbdcbe 100644
--- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ cookie +.idea*

注:git show 接標籤名可查看當前項目指定標籤具體信息

上傳標籤

命令:git push origin v0.1.0

參數說明:

須要在push時指定遠程倉庫（默認當前分支）,後加標籤名.

例子:

 

meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ touch test meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ ls headers memorandom.txt rename.py*  scrap.py* test meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git add . meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git commit -m'test' [master b57b583] test 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 test meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git push Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 32 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 255 bytes | 255.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), completed with 1 local object. To https://github.com/545641826/scrap_bilibili.git
   b30d3b3..b57b583  master -> master

此時可在git上看到如圖所示標籤

回退到標籤版本

新建文件模擬bug

 

此時遠程倉庫如圖:

回退:

首先經過標籤查看提交id

而後經過reset --hard 回退到指定提交版本.

最後提交

meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git show v0.1.0 tag v0.1.0 Tagger: unknown <545641826@qq.com> Date: Mon May 27 04:58:08 2019 +0800 init commit b30d3b3e00a93e43d8219ca584b4ce380c6f6be8 (tag: v0.1.0) Author: ylin <545641826@qq.com> Date: Tue Dec 11 11:46:10 2018 +0800 first commit diff --git a/.gitignore b/.gitignore index 871bb87..8fbdcbe 100644
--- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ cookie +.idea* meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ git reset --hard b30d HEAD is now at b30d3b3 first commit meel@YLIN-VPC MINGW64 /t/Desktop/scrap_bilibili (master) $ ls headers memorandom.txt rename.py*  scrap.py*

10. 你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？ 修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？

    在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？

    在程序員提交簽入以後，服務器上是否有自動測試程序， 完成編譯，測試，若是成功，就簽入，不然，就取消簽入？

    團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

 

1：測試相關代碼和源代碼都在同一個項目的同一個文件夾下，至關因而放在一塊兒了。 修改了源代碼，相關測試會自動更新。團隊暫時沒有部署自動構建任務

2：自動測試暫時尚未去作，因此這一步可能還未涉及到

3：還未涉及到服務器以及自動測試相關，因此這一步暫時沒有

4：暫未配置服務器，因此暫時沒有自動同步以及相關功能

 

心得體會：

   在作這項做業的時候，咱們團隊一開始不少人都針對這些問題有許多不理解的點，和不理解的專業術語專業問題等等，但在咱們探索的過程當中和團隊間的互相交流中咱們瞭解了許多其餘的輔助咱們團隊開發的軟件，以及對於協助團隊更改更新代碼的軟件，經過解答問題，咱們團隊對於這些軟件的操做也越發熟練起來，針對源文件簽入，bug修改，查找歷史修改文件，爲全部源文件打上標籤，同步全部有這個標籤的文件版本，自動運行單元測試，從一開始的需求分析，到軟件製做，到軟件技術層面上的代碼bug修改，到最後的測試環節，在本報告中所說起的問題中都有所涉及，咱們在思考探索若是自動同步全部文件，自動構建，自動運行單元測試，碰到錯誤如何可以自動發郵件給團隊，等等咱們以往從未考慮到的問題，或者考慮到但從未想過該如何解決的問題時，經過這項做業咱們每個成員都有了新的思考和結果，咱們也學會了如何運用軟件協助咱們完成一個新的項目，並監督每一個成員期間的過程和操做，推進整項項目的順利進展。