Git工程開發實踐（六）——Git工程實踐擴展

時間 2019-11-05

標籤 git 工程開發實踐擴展欄目 Git 简体版

原文原文鏈接

Git工程開發實踐（六）——Git工程實踐擴展

1、Git提交日誌規範

一、Git提交日誌模板

Git支持對每次提交的日誌信息進行規範，能夠經過設置提交模板實現。
創建一個gitCommitTemplate文件，內容爲：html

#commit message包含三部分，header, body和footer，其中header必選，body和footer可選。
# type(<scope>): <subject>

#<body>

#<footer>

#type字段包含：
    # feature:新功能開發
    # update:功能修改
    # bugfix：bug修復
    # refactor：重構（非新增功能、非bug修復）
    # docs：文檔（documentation）
    # style：格式（不影響代碼運行的變更）
    # test：增長測試
    # chore：構建過程或輔助工具的變更

#scope用於說明commit影響的範圍，好比數據層、控制層、視圖層等等，不一樣項目不一樣。

#subject是commit目的的簡短描述，不超過50個字符。
    #以動詞開頭，使用第一人稱如今時，好比change，而不是changed或changes。
    #第一個字母小寫。
    #結尾不加句號（.）。

#body部分是對本次commit的詳細描述，能夠分紅多行。
    #使用第一人稱如今時，好比使用change而不是changed或changes。
    #應該說明代碼變更的動機以及與之前行爲的對比。

#footer
    #A、若是當前代碼與上一個版本不兼容，則footer部分以BREAKING CHANGE開頭，     
    #   後跟對變更的描述、變更理由以及遷移方法。

    #B、關閉Issue,關閉某個issue能夠：close #issue_id，多個使用逗號分隔

Revert撤銷操做
若是當前commit用於撤銷之前的commit，則必須以revert:開頭，後面跟着被撤銷Commit的Header。ios

revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body部分的格式是固定的，必須寫成 This reverts commit commit_id. ，其中的hash是被撤銷commit的 SHA 標識符。若是當前commit與被撤銷的commit，在同一個發佈（release）裏面，那麼都不會出如今Change log 裏面。若是二者在不一樣的發佈，那麼當前commit，會出如今Change log的Reverts小標題下面。git

二、Git提交日誌模板設置

設置當前分支的提交模板github

git config commit.template [模板文件名]   
git config commit.template gitcommit_template

設置全局的提交模板編程

git config --global commit.template [模板文件名]   
git config --global commit.template gitcommit_template

設置文本編輯器vim

git config --global core.editor [編輯器名稱] 
git config --global core.editor vim

三、Git提交日誌填寫

使用git commit -a提交時，Git會用設置的編輯器打開設置的提交日誌模板，而後按照格式添加相應的備註，保存提交到遠程分支。服務器

2、Git代碼統計

Git能夠經過對log的分析進行代碼統計。
git log參數說明：
--author
指定做者
--stat 顯示每次更新的文件修改統計信息，會列出具體文件列表
--shortstat 統計每一個commit 的文件修改行數，包括增長，刪除，但不列出文件列表：
--numstat 統計每一個commit 的文件修改行數，包括增長，刪除，並列出文件列表：
-p 選項展開顯示每次提交的內容差別，用 -2 則僅顯示最近的兩次更新，例如：git log -p -2
--name-only 僅在提交信息後顯示已修改的文件清單
--name-status 顯示新增、修改、刪除的文件清單
--abbrev-commit 僅顯示SHA-1的前幾個字符，而非全部的40個字符
--relative-date 使用較短的相對時間顯示
--graph 顯示ASCII圖形表示的分支合併歷史
--since 限制顯示輸出的範圍，
例如：git log --since=2.weeks 顯示最近兩週的提交
選項說明
-(n) 僅顯示最近的 n 條提交
--since, --after 僅顯示指定時間以後的提交。
--until, --before 僅顯示指定時間以前的提交。
--author 僅顯示指定做者相關的提交。
--committer 僅顯示指定提交者相關的提交。編輯器

git log --until=1.minute.ago // 一分鐘以前的全部 log 
    git log --since=1.day.ago //一天以內的log 
    git log --since=1.hour.ago //一個小時以內的 log 
    git log --since=`.month.ago --until=2.weeks.ago //一個月以前到半個月以前的log 
    git log --since ==2013-08.01 --until=2013-09-07 //某個時間段的log   
    git blame //看看某一個文件的相關歷史記錄
    git blame index.html --date short

--pretty 使用其它格式顯示歷史提交信息。可用的選項包括 oneline，short，full，fuller 和 format（後跟指定格式）。
git log --pretty=oneline ;
git log --pretty=short ;
git log --pretty=full ;
git log --pretty=fuller
--pretty=tformat: 能夠定製要顯示的記錄格式，便於後期編程提取分析。
git log --pretty=format:""%h - %an, %ar : %s""
%H 提交對象（commit）的完整哈希字串
%h 提交對象的簡短哈希字串
%T 樹對象（tree）的完整哈希字串
%t 樹對象的簡短哈希字串
%P 父對象（parent）的完整哈希字串
%p 父對象的簡短哈希字串
%an 做者（author）的名字
%ae 做者的電子郵件地址
%ad 做者修訂日期（能夠用 -date= 選項定製格式）
%ar 做者修訂日期，按多久之前的方式顯示
%cn 提交者(committer)的名字
%ce 提交者的電子郵件地址
%cd 提交日期
%cr 提交日期，按多久之前的方式顯示
%s 提交說明
git log --author="username" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }'
統計用戶名爲username的開發者增刪的代碼行數
git log --author="$(git config --get user.name)" --pretty=tformat: --numstat | gawk '{ add += $1 ; subs += $2 ; loc += $1 - $2 } END { printf "added lines: %s removed lines : %s total lines: %s\n",add,subs,loc }'
統計當前用戶增刪的代碼行數
git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --author="$name" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
統計每一個開發者增刪的代碼行數
git log --pretty='%aN' | sort | uniq -c | sort -k1 -n -r | head -n 5
統計倉庫提交者排名前5的開發者
git log --pretty='%aN' | sort -u | wc -l
統計倉庫貢獻者的數量
git log --oneline | wc -l
倉庫提交數量統計ide

3、Git代碼託管工程實踐

一、Git代碼託管簡介

目前主流的Git在線代碼託管工具以下：
GitHub：https://github.com
GitHub是一個面向開源及私有軟件項目的託管平臺。
Gitee(碼雲)：https://gitee.com
中國本土的在線代碼託管協做開發平臺。
GitLab:https://gitlab.com
GitLab是一個用於倉庫管理系統的開源項目，支持無限公有項目和私有項目，支持在局域網內使用GiLab CE搭建代碼託管服務器。工具

二、Pull Request機制

Pull Request是集成管理者工程流程在GitHub上的工程實踐，是開發者使用GitHub進行協做開發的一種通知機制，讓開發者通知項目成員一個功能已經完成。若是功能分支開發完畢，開發者使用GitHub帳號提交一個Pull Request，通知全部參與者須要進行代碼審查，並將代碼併入master分支。Pull Request還提供了專一於某個提交功能的討論版。
Pull Request的工做流程以下：
A、開發者從某個項目的官方倉庫Fork一份拷貝到本身GitHub帳戶，此時開發者的GitHub帳戶會有一份項目官方倉庫的拷貝。
B、開發者將本身遠程倉庫的項目副本克隆到本地
C、開發者在本身本地倉庫爲某個功能建立一個專門的分支，並完成功能開發。
D、開發者將開發完成的功能分支推送到本身GitHub帳戶的公開倉庫。
E、開發者用GitHub發起一個Pull Request。
F、其餘團隊成員審查代碼，討論而且作出修改。
G、項目維護者將功能併入官方倉庫，而後關閉Pull Request。

三、Pull Request示例

scorpio是HyperLedger Fabric的開發者，Mary是HyperLedger Fabric項目的維護者。HyperLedger Fabric在GitHub的官方倉庫地址以下：
https://github.com/hyperledger/fabric
A、將HyperLedger Fabric項目官方倉庫fork到本身的GHub帳戶。
爲了參與HyperLedger Fabric項目，scorpio首先要fork HyperLedger Fabric項目在GitHub的官方倉庫。scorpio須要註冊登陸 GitHub，找到HyperLedger Fabric的官方倉庫，點擊Fork按鈕。

此時，GitHub會在scorpio帳戶中派生一份HyperLedger Fabric的官方倉庫的拷貝。
B、將本身GitHub帳戶中的HyperLedger Fabric項目副本克隆到本地。
scorpio須要將剛剛fork的GitHub倉庫克隆到本地。
git clone https://github.com/scorpiostudio/fabric
git clone自動建立一個名爲origin的遠端倉庫，指向scorpio本身GitHub帳戶中的fabric倉庫（https://github.com/scorpiostudio/fabric）。
C、在本地倉庫建立feature分支
在進行開發前，scorpio須要建立一個新的功能分支some-feature。
git checkout -b some-feature
D、在新建的feature分支上完成功能開發
scorpio在當前分支some-feature上進行功能開發，最終完成。
E、將本地倉庫開發的功能分支推送到開發者本身的GitHub帳戶的遠程倉庫。
在完成some-feature功能開發後，scorpio將some-feature分支推送到本身的GitHub倉庫（https://github.com/scorpiostudio/fabric）上。
git push origin some-feature
此時，scorpio開發的some-feature功能就能夠被其餘人看到。
F、開發者在GitHub上的項目官方倉庫建立一個Pull Request
scorpio須要找到HyperLedger Fabric項目的官方倉庫（https://github.com/hyperledger/fabric），點擊項目簡介下的New pull request按鈕，使用本身的GitHub賬號建立一個Pull Request。

scorpio的倉庫會被默認設置爲源倉庫（head fork），詢問指定源分支（compare）、目標倉庫（base fork）和目標分支（base）。

scorpio想要將本身開發的some-feature功能併入主代碼庫，因此源分支是scorpio的some-feature分支，目標倉庫就是HyperLedger Fabric項目的官方倉庫，目標分支爲master。scorpio須要提供一個Pull Request的標題和簡介。
在scorpio建立一個Pull Request後，GitHub會給HyperLedger Fabric項目的維護者Mary發一個通知。
G、項目官方倉庫的維護者審查開發者提交的功能分支
Mary能夠在本身的GitHub倉庫下的Pull Request選項卡中看到全部的 Pull Request。點擊scorpio的Pull Request會顯示Pull Request的簡介、some-feature分支的提交歷史以及包含的更改。
H、項目官方倉庫的維護者接受開發折提交的功能分支並關閉Pull Request
若是Mary認爲some-feature分支已經能夠合併，只需點擊Merge Pull Request按鈕來經過當前的Pull Request，將scorpio提交的some-feature分支併入HyperLedger Fabric官方倉庫的master分支。
若是Mary發現了scorpio代碼中的一個小bug，須要scorpio在合併前修復。Mary能夠評論整個Pull Request，也能夠評論some-feature分支中某個特定的提交。
爲了修復錯誤，scorpio在本身本地倉庫some-feature分支後面添加了另外一個提交，並將它推送到了GitHub遠程倉庫。此時修復bug的提交被自動添加到原來的Pull Request後面，Mary能夠在評論下方再次審查scorpio的修改。
最終，通過屢次修改後，Mary接受了scorpio提交的功能，將some-feature分支併入HyperLedger Fabric官方倉庫master分支，並關閉scorpio建立的Pull Request。如今some-feature功能如今已經整合到了HyperLedger Fabric項目中，其餘在master分支上工做的開發者可使用標準的git pull命令將上述修改拉取到本身的本地倉庫。

四、Merge Request機制

Merge Request是集成管理者工程流程在GitLab上的工程實踐。
用Admin或Owner或Master帳號登陸，打開指定project -> Settings -> Repository -> Protected Branches，選擇要protect的branch （支持wildcard）：
要求每一個人都要經過Merge Request才能合併代碼進入public branch：選擇」Allowed to merge」爲」Developers + Masters」，選擇」Allowed to push」爲」No one「。

Merge Request工做流程以下：
A、從項目的官方倉庫fork一份拷貝到GitLab的我的帳戶。此時我的帳戶有一份項目官方倉庫的拷貝。
B、將我的帳戶的項目倉庫克隆到本地
C、在本地倉庫建立一個新的本地分支，進行任務開發，開發完成後推送到我的GitLab帳戶的遠程倉庫，此時Git會提示進行Merge Request。

D、開發者登陸GitLab帳戶，在fork的官方項目副本上發起Merge Request。打開項目，點擊右側的Create merge request。

選擇Source branch和Target branch，Source branch分支爲我的GitLab帳戶中的遠程倉庫分支，Target branch分支爲GitLab官方倉庫的分支

點擊」Compare branches and continue「

填寫標題和表述信息。
選擇Assignee（指派給誰）（不要選擇Assign to me）
若是是臨時branch，勾選「Remove source branch when merge request is accepted」
檢查無誤後，點擊「Submit merge request」按鈕。
若是發起Merge Request後，在本Merge Request關閉前，繼續往source branch分支push代碼，後續commit也會被自動包含在本Merge Request裏。
E、其餘人進行代碼審查，經過Merge Request。
被指派者登陸GitLab我的帳戶，點擊由上角Merge Request，查看當前的Merge Request任務。

點擊Merge Request任務進入

點擊Commit查看詳細信息
點擊Changes查看具體的改動
寫comment，並和代碼提交者討論。
審查經過後，點擊」Merge」按鈕
若是審查不經過，寫清楚comment，並在和代碼提交者討論後，要求其進行修改。
F、結果查看
點擊GitLab上的項目官方倉庫，選擇相應的分支，能夠看到，開發者Merge Request申請合併的分支已經併入了官方倉庫。

上述實驗在GitLab CE（社區版）中進行，所以實際上發起Merge Request申請的人或是其餘人，只要具備Merge權限均可以進行Merge。
GitLab CE（社區版）發起Merge Request時，全部具有Merge的項目成員均可以Merge；
GitLab EE（企業版）加入了權限管理審批機制（Merge Request Approvals），只有指派的成員才能夠Merge。

五、選擇分支策略的原則

選擇分支策略的原則：
A、始終保持master處在可發佈狀態
B、始終保持構建處在成功狀態
C、下降代碼合併的複雜度和風險
D、下降團隊溝通成本
E、符合團隊的現狀

六、代碼審查的原則

代碼審查的原則：
A、不要既當運動員，又當裁判員。
B、審查代碼是否知足功能、規範、測試結果、測試覆蓋等。
C、藉助自動化代碼審查工具來提高代碼審查的效率。
D、審查合格才容許併入public branch，不合格的代碼退回從新修改。
E、不怕犯錯，但不要犯重複的錯。
F、提交審查前，本身先檢查一遍。
G、鼓勵使用同行評審（Peer Review）而不是上下級評審，鼓勵積極反饋、互動。
H、評審對事不對人，多建議，不批評
I、評審過程對reviewer和代碼提交者雙方都是一個學習提高的過程，保持開放的心態，相互學習，共同成長。

4、Git GUI工具

GUI Clients：https://www.git-scm.com/downloads/guis
部分提供免費版的Git客戶端以下：
SourceTree：Windows，Mac（支持Git Flow）
GitHub Desktop：Windows，Mac（支持Pull Request）
TortoiseGit：Windows
Git Extensions：Linux, Mac, Windows
GitKraken：Linux, Mac, Windows
SmartGit：Linux, Mac, Windows(支持Git Flow,Pull Request)
CodeReview：Linux, Mac, Windows
GitEye：Linux, Mac, Windows
GitGUI： Linux, Windows(Git官方GUI客戶端)

5、主流IDE對Git的支持

目前軟件開發的主流IDE經過插件方式支持Git。Eclipse ：經過Egit插件提供Git集成支持。Visual Studio：經過Git Integration、GitHub Extension等Git插件提供Git集成支持。QtCreator：經過Git插件提供Git集成支持(QtCreator高版本支持GitK，GitGUI)。IntelliJ IDEA：經過GitXXX插件提供Git集成支持。