git配置以及替換gerrit預設commit-msg hook

記得要微笑 發表於 2022-06-27
MIT Git

Git 配置規範

配置使用者名稱和郵件

為了提交記錄便於識別,配置中文名,郵箱配置成gitlab註冊郵箱

git config --global user.name "中文姓名"  
git config --global user.email "[email protected][email.com"

示例

user.name 配置規則: name#工號 示例 git config --global user.name "張三#A00003"

user.email 配置規則: 統一使用公司的郵箱。示例 git config --global user.email "[email protected]"

保持倉庫中以 LF 換行

git config --global core.autocrlf input // 因為linux服務預設使用LF作為換行符格式

參考資料:git core.autocrlf配置說明

git中文路徑名稱亂碼

git config --global gui.encoding utf-8  
git config --global core.quotepath false

git mergetool不再生成煩人的備份檔案(*.orig

git config --global mergetool.keepBackup false

讓檔名區分大小寫

git config --global core.ignorecase false

不修改檔案模式(檔案mode變化不提交到倉庫)

git config --add --global core.filemode false

檔案重新命名不生效(大小寫不敏感)時,請使用 git mv 重新命名

git mv lineConfig.js LineConfig.js

為了方便您的配置,您可以直接執行以下指令碼 git_config_default.sh

# git_config_default.sh
# 配置使用者名稱和郵件
# 為了提交記錄便於識別,配置中文名,郵箱配置成gitlab註冊郵箱
# user.name 配置規則: name#工號  示例   git config --global user.name "譚智軍#A00015"  
# user.email 配置規則: 統一使用公司的郵箱。示例 git config --global user.email "[email protected]"  

read -p "請輸入您的姓名和工號,示例為:王永林#A00514.輸入後請按[enter]鍵結束。" USER_NAME
git config --global user.name "$USER_NAME" 
echo "設定後 user.name 值為 "
git config user.name
# TODO user.name 符合正則 [\u4e00-\u9fa5]{2,}#[A-B]\d{5} 才可以繼續輸入

read -p "請輸入您在gitlab上註冊的公司郵箱,示例為:[email protected]輸入後請按[enter]鍵結束。" USER_EMAIL
git config --global user.email "$USER_EMAIL" 
echo "設定後 user.email 值為 "
git config user.email

#保持倉庫中以 LF 換行
git config --global core.autocrlf input
echo "git config --global core.autocrlf input"

#git中文路徑名稱亂碼
git config --global gui.encoding utf-8   
git config --global core.quotepath false
echo "git config --global gui.encoding utf-8"
echo "git config --global core.quotepath false"

#讓git mergetool不再生成煩人的備份檔案(*.orig)
git config --global mergetool.keepBackup false
echo "git config --global mergetool.keepBackup false"

#讓檔名區分大小寫
git config --global core.ignorecase false
echo "git config --global core.ignorecase false"

#不修改檔案模式(檔案mode變化不提交到倉庫)
git config --add --global core.filemode false
echo "git config --add --global core.filemode false"

使用方式如下:

Windows

第一步:把git_config_default.sh另存到指定的系統目錄下;

第二步:在該目錄右鍵 選擇【Git Bash Here】進入Git命令列介面;

第三步:輸入以下命令

chmod 777 git_config_default.sh

./git_config_default.sh // 執行git_config_default.sh指令碼

執行示例如下:

image2022-2-28_17-41-42.png

Mac

第一步:把git_config_default.sh另存到指定的系統目錄下;

第二步:在該目錄右鍵 選擇【進入終端】進入Git命令列介面;

第三步:輸入以下命令

chmod 777 git_config_default.sh
./git_config_default.sh

示例如下:

image2022-2-28_17-41-42.png

Git 提交規範

目的

git commit資訊作為一個基礎的互動視窗,既可以快速確定提交影響、關聯設計文件、關聯缺陷bug單、後續還能對專案或團隊工作進行溯源改進。

git commit資訊的規範化,既體現開發同學的專業素養,也屬於公司的過程資產,因此對git commit提交的規範設計如下。

規範

commit提交規範中,明確本次提交格式

【提交型別】

​ 明確 一次程式碼提交的目的。要麼是新增功能(feat),要麼是修復bugfix),再者依賴、構建、配置升級、測試程式碼等等(other)。

【提交說明】

​ 明確提交目的後,我們還需要看看具體內容。通過關鍵字描述提交詳情,更明確的傳遞提交的價值。

【相關連結】

​ 方便支援介面設計、story設計、需求、bug描述等不同型別程式碼提交的需求,我們同時支援JIRAconfluence連結。

為了方便使用,我們採用Angular規範,如下:

git提交規範

規範說明
      提交型別(必須):
        feat(新增功能)
        fix(修復bug)
        other(依賴,構建、CI、格式等,可通過提交資訊說明)
      提交說明 (必須):描述此次提交所修改的內容(長度限制2~100, 約定說明中不要包含"[]", 會影響校驗規則)
      相關連結 (必須):Jira 連結或 Confluence 連結 
規範格式
      提交型別:  提交說明  [相關連結] 
提交示例 
     feat:  git提交規範說明  [https://jira.casstime.com/EC0001] 

關於規範的常見問題

問題1:story編寫或者釋出階段沒有jira,強制jira編號的不知道如何填寫,只能提前建立Jira

針對這個問題,我們和開發同學進行了溝通,我們把之前強制要求填寫jira編號 改成了強制要求填寫相關連結,這樣在story設計階段可以填寫 storyconfluence地址, 釋出階段可填寫checklist地址。

問題2:提交型別太少,不知道如何選擇,比如說以下場景,修改ci, 正式版本打包,調整程式碼格式,程式碼重構,效能優化等等

針對這個問題 ,我們還是堅持不增加新的型別,但是把原來的refactor修改為other

  • 不增加提交型別的原因

​ 一個原因為了約束提交時的程式碼完整性,我們推薦的是一次提交對應的一個具體的story功能,不推薦一個功能出現多次提交的情況 ,如果型別給的太多,那麼我隨意修改一次程式碼的時候,就可以有對應的型別來選擇,程式碼完整性上就沒有約束性。另一個原因也是越簡單越容易理解,每個人都有自己的理解,比如說,我修改了一個pom的版本重新打包,但是現在型別有 cibuild,那這個場景該如何選擇,相信有人會認為是ci,也有人會認為是build

  • 提交型別如何選擇

​ 針對程式碼重構,效能優化這2個場景沒有型別,從迭代的角度說,這2個場景也是屬於增加新功能或者修復bug,因為做2個任務的時候,肯定是需要對應的storyjira來跟蹤。 可能確實會存在一些場景需要特殊調整,但是一般這種場景都是低頻的,選擇other,加上對應的描述即可,大家也可以理解為符合angular提交的那些型別現在變成了子型別,只是說這個子型別是放到了描述當中

校驗

此節主要是描述現有工程專案如何整合commit-msg hookCommit資訊進行驗證。初步想法是利用githooks來進行驗證,當執行git commit 命令後,便會自動觸發此hook,然後對提交的commit 資訊進行格式的驗證。

小提示

Git Hook 大致分為兩種,一個在服務端,一種放在本地。其中,本地的 hook 不受版本控制器的管理,也就是說我們沒辦法把寫好的 hook 指令碼放在.git/hooks下面,然後推送到倉庫,供小夥伴們下載、使用(除非自己將hook檔案手動複製到專案的./git/hooks目錄下)

經過對gerrit程式碼稽核平臺的分析,我們已經解決了需要開發同學手動執行命令下載commit-hooks的問題,對如何解決這個問題的同學可參考下面:

gerrit如何替換預設的commit-hook檔案

如何整合我們自定義hook進行提交資訊檢查上,並且讓開發同學什麼都不用做便可獲取到我們提供的規範檢查hooks?起初遇到了很多問題,命令列、外掛方式都進行過嘗試,但是都沒有很好的解決這個問題,還是需要開發同學手動執行才行,為了很好的解決這個問題,

我們首先在gerrit程式碼稽核平臺上clone一個工程的命令:

clone工程命令

## SSH方式
git clone "ssh://[email protected]:29418/open/icec-cloud-job" && scp -p -P 29418 [email protected]:hooks/commit-msg "icec-cloud-job/.git/hooks/"

## HTTP方式
git clone "http://[email protected]:8087/a/open/icec-cloud-job" && (cd "icec-cloud-job" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg http://[email protected]:8087/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)

## ANONYMOUS HTTP方式
git clone "http://gerrit.casstime.net:8087/open/icec-cloud-job" && (cd "icec-cloud-job" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg http://gerrit.casstime.net:8087/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)

可以看到,命令被分為了2個部分,一個部分是執行clone程式碼操作, 一個部分是執行下載gerrit提供hooks操作,由此可知,gerrit是提供了預設的commit-hook檔案的,我們只要對其進行替換即可。

基於以上的分析,我們做了以下的操作步驟

image2022-5-19_15-54-40.png

注:文件中的lib位置是錯誤的,真正需要替換是截圖中的lib包,替換完成重啟既可, 不需要執行初始化等步驟

操作步驟

小提示 (前端開發同學注意)

git提交規範試行的過程中,前端工程的好像是整合了一個husky外掛,覆蓋了工程.git/hooks下的檔案,針對這個情況,前端這邊的工程,由SE自己決定是繼續使用 husky外掛 或者 使用我們推薦的方式

1、如果是還未clone的工程,正常clone工程即可,其它的什麼都不用做,我們已經替換了gerrit預設的commi-hook檔案,校驗檔案會隨clone命令自動克隆到工程的.git/hooks目錄下。

2、如果是在git提交規範規範推行之前已經clone到了本地的工程,則需要自己手動執行命令下載commit-hook,命令如下

hook下載命令

# 如果clone的專案是gerrit專案,則執行此命令
curl -Lo .git/hooks/commit-msg http://10.2.43.24:3311/commit-msg
 
# 如果clone的專案是gitlab專案,則執行此命令
curl -Lo .git/hooks/commit-msg http://10.2.43.24:3311/commit-msg-nogerrit

3、執行後,開啟專案.git/hooks目錄下的commit-msg檔案,如果看到以下資訊,說明已經成功下載了commit-hook

image2022-4-18_10-7-28.png

示例

模擬一個不符合規範的提交,當執行commit動作後,會提示不符合規範,然後在控制檯輸出相應的提交規範說明

  • 示例1:模擬命令列提交不通過

image2022-4-13_15-4-10.png

  • 示例2:模擬IDEA 提交不通過

image2022-4-13_15-4-58.png

相關文章