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

Git 配置規範

配置使用者名稱和郵件

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

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

示例

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

user.email 配置規則: 統一使用公司的郵箱。示例 git config --global user.email "san.zhang@casstime.com"

保持倉庫中以 `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 "zhijun.tan@casstime.com"  

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上註冊的公司郵箱，示例為：yonglin.wang@casstime.com.輸入後請按[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指令碼

執行示例如下：

Mac

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

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

第三步：輸入以下命令

chmod 777 git_config_default.sh
./git_config_default.sh

示例如下：

Git 提交規範

目的

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

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

規範

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

【提交型別】

明確一次程式碼提交的目的。要麼是新增功能（feat），要麼是修復bug（fix），再者依賴、構建、配置升級、測試程式碼等等（other）。

【提交說明】

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

【相關連結】

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

為了方便使用，我們採用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設計階段可以填寫 story的confluence地址，釋出階段可填寫checklist地址。

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

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

不增加提交型別的原因

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

提交型別如何選擇

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

校驗

此節主要是描述現有工程專案如何整合commit-msg hook對Commit資訊進行驗證。初步想法是利用git的hooks來進行驗證，當執行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://a00514@gerrit.casstime.net:29418/open/icec-cloud-job" && scp -p -P 29418 a00514@gerrit.casstime.net:hooks/commit-msg "icec-cloud-job/.git/hooks/"

## HTTP方式
git clone "http://a00514@gerrit.casstime.net: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://a00514@gerrit.casstime.net: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檔案的，我們只要對其進行替換即可。

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

注：文件中的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

示例

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

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

示例2：模擬IDEA 提交不通過