記得原來有一次聽到一個開發同學抱怨說為啥每次Commit都必須要填寫commit message呢？他覺得有些浪費時間，因此想出了各種辦法來應對，比如輸入一個句點或復制粘貼上個commit message等。這種一時偷懶的做法，卻會給其他合作開發的伙伴帶來很多煩惱，這些不知所云的commmit message不僅不能很好代表每次代碼提交的用途，還會成為垃圾信息給團隊帶來干擾。

git commit -m “.”

不過現在很多開發團隊已經通過約定代碼提交規范來約束提交信息的規范化，比如必須包含類型(新功能、修復缺陷或者增加測試等)和主題(提交代碼的簡短描述)信息。

git commit -m “feature：用戶查詢接口開發”

可以看到在代碼提交信息中增加目的描述，是為了使代碼的作用通過文字顯式地展示出來。比如一看提交信息就知道這段代碼是為了開發某個新的需求功能，而不用去通過逐行瀏覽代碼才能了解其含義。更進一步的做法是，直接使代碼的提交與需求、任務或者缺陷等建立關聯。拿GitHub舉例，需求和缺陷都可以通過issue來進行管理，而只每次在代碼提交信息中輸入issue的ID就可以了，如下：

git commit -m “#10 issueid”

還可以通過在commit信息中輸入close等指令來實現issue狀態的修改，如下：

git commit -m “close #10 issueid”

直接通過git命令就實現了issue的關閉：

為什么代碼提交要關聯需求和任務信息

看到這里，我想你可能要問：我為什么要每次提交代碼的時候，要費勁地先去查詢下IssueID呢，這樣做能帶來什么收益呢？下面我就來給你捋一捋：

1. 研發過程資產的可度量

代碼是一種很重要的研發過程資產，而其原生狀態又是一種非結構化的數據信息，無法很直觀的與管理者所關注的項目或者需求關聯起來。如果沒有好的數據管理和度量機制，管理者角度就只能通過會議和溝通等手段從一線工程師那里獲取一些主觀的描述。如需求和任務的工作量大小、細化到需求和任務維度的代碼質量和風險等數據，這些數據在做項目復盤、資源評估、質量和風險評估等環節都是非常重要的參考依據。

通過提交信息中關聯需求和任務ID，就可以得到以下的數據：

以上是基礎數據的匯總計算，還可以引入需求和任務維度的代碼復雜度、代碼當量和測試覆蓋率等數據。

2. 精細化的代碼質量和風險管控

質量和風險的管控都是需要投入成本的，而通過實現代碼和需求及任務的關聯，可以設計更細粒度的質量和風險管控策略，在早期的質量預防、中期的風險發現和后期的問題復盤都可以很大程度上減少成本投入。目前大家所說的精準化測試的方法就是基于此策略，設計測試策略時可以依據需求來劃定代碼變更范圍，再針對一定范圍內的代碼變更來設計高覆蓋率的測試策略，從而避免由于全量執行測試用例帶來的高成本。

另外還可以把代碼掃描、單元測試和代碼評審等質量卡點與需求和任務的流轉狀態相關聯，做到需求和任務維度的質量內建和測試左移。

3. 開發者視角的收益

如果你是一位一線工程師，看完以上兩點收益，肯定會覺得這都是管理的訴求，那從工程師的視角來看又會有哪些收益呢？

(1) 減少為了研發效能度量而做一些額外工作

研發效能度量，需要度量需求的在各個階段的停留時長，比如開發時長，比較傳統的做法是需要研發同學開始寫代碼的時候，在研發協同平臺上更新下需求和任務的狀態，寫完了提交測試后再去更新狀態。這些重復性的工作，還是需要占用不少時間的，那么通過需求任務和代碼提交建立關聯，就可以通過代碼提交等事件來自動化觸發需求和任務狀態的流轉，這樣還能自動把對應的開始時間和結束時間都自動記錄下來，從而便于高效和準確地開展研發效能度量。

(2) 從代碼為主的技術視角逐步擴展到關注需求價值的全局視角

由于管理者和業務方更關注需求價值和項目交付進度，而一線研發工程師往往更加關注技術細節，這樣就容易造成管理者和業務視角獲得的信息和工程師視角之間的割裂，比如作為研發leader為了緊急的項目或者需求焦慮不已，而作為一線工程師又各自在沉浸在自己的代碼世界里不明所以。那么通過代碼提交和需求任務建立關聯，開發工程師關注代碼本身的同時，還可以通過匯總代碼倉庫級或者版本所實現的需求價值和完成的開發任務，從而能夠更加關注業務價值，通過技術視角和業務視角的結合，助推技術職業生涯的更好發展。

代碼關聯需求和任務的功能擴展

文章的前面只是介紹了從命令行提交代碼的時候，如何與需求和任務信息建立關聯。而要帶來更多的收益，只有這個功能就不能完全滿足了。完整的功能一般通過與協作工具的配合來完成，如Jira就實現需求/任務和開發分支的關聯，還可以通過配置工作流來實現在線創建分支的同時觸發需求/任務的狀態變化(進入開發狀態)。下圖為需求/任務卡片詳情頁面的開發信息的展示，可以看到關聯了一個開發分支，可以通過點擊分支到代碼庫的分支詳情頁面。

“功能拓展建議：在需求/任務已經關聯一個代碼分支的前提下，可以通過規則設定實現該分支下的所有代碼提交都自動關聯，這樣就不需要每個Commit信息里都填寫需求和任務ID信息了。”

目前很多協同平臺的做法是，除了實現除了提交信息和分支與需求/任務的關聯，還可以關聯代碼庫的合并請求。另外還可以實現需求/任務與測試過程資產的關聯。

具體的實現方式有兩種：一種是在協同平臺的需求/任務卡片上通過手動操作來選擇需要關聯的信息，第二種是通過代碼倉庫和測試管理系統這樣的三方工具平臺主動上報關聯的需求和任務信息。

結語

代碼提交關聯需求和任務的功能雖然不大，確實一個良好習慣的養成，在此基礎上逐步實現更加豐富的代碼過程資產與需求和任務的關聯，從而為效能度量、質量和風險管控等提供更多的便利。研發效能提升包含兩個層面，一個是單點任務的效能提升，如環境部署和測試等；另外一個就是不同角色成員之間的協同效能提升，而代碼信息與需求任務信息的關聯，就是通過過程數據的可視化使關注需求和任務的角色成員與關注代碼的工程師實現更好的協同。