iT邦幫忙

6

多人開發 Git規範參考

  • 分享至 

  • xImage
  •  

前言

工作幾年偶爾會看到Git commit記錄寫上了一堆bug fix或者modify UI之類的
說實在這樣寫過兩個月回去看沒有按照每一筆紀錄看過程式,根本不知道改過什麼
在第一間公司用SVN版本控管時有經過一些訓練,雖然不至於到很詳細,但至少看紀錄都猜得到是哪個方向

這邊分享的是另一種算是更進階版的紀錄,正確名稱應該叫做Git Flow
以下的範例不一定跟Git Flow 100%相同,主要是團隊參考過Git Flow一起定義出來的開發規範

開發規範

  1. 所有進行開發前需要先填寫Issue,修正Bug或新增功能都要
    Bitbucket->Repository->Issues(Menu)->Create issue
    https://ithelp.ithome.com.tw/upload/images/20200504/20126774aPyps7UkPg.png
  • 修正Bug範例(kind bug)
    測試環境:發現 bug 的環境,可以是 開發/QA/Production,如果有其它環境,填寫相應的內容
    軟件版本:發現 bug 的版本
    測試時間:發現 bug 的時間
    報告者:發現 bug 的人
    操作描述:發現 bug 時進行的操作過程的描述,可以添加圖片、視頻等
    期望結果:按照正確的實現,期望上面操作的結果是什麼
    實際結果:實際測試的結果是什麼
    分析:分析出現 bug 的原因,要包括思路,和證據(比如 log 的內容,db 數據等)。這項是可選項,可以不寫。但對原因復雜的,或者查找原因的過程比較曲折
    結論:bug 發生的原因
    解決方案:修復 bug 所使用的方案
  • 調整功能範例,應至少寫明調整前後的狀態,最好可以包含原因(kind enhancement)
    狀態:移除User XX狀態判斷,所有位置統一使用Role XX狀態作為判斷依據
    原因:避免規則過於複雜導致客戶難以理解
  • 新功能範例,應包含新功能描述,功能特殊規則(kind enhancement)
    需求:新增設定User Pin Code功能
    規則:
    Pin Code設定判斷規則(4位數字、不得為連續數字、不得為重複數字)
    Pin Code需要透過API更新至客戶內部系統(API文件請參考 XX網址)
    資料庫XX資料表需要新增XX欄位
  • 重構(kind task)
    目標:A功能與B功能都有取得XX清單功能,但條件不同,可整合至同一個Function以帶入參數的方式處理
  1. 所有的Issue不直接在master/develop/release分支上進行,應另外開分支
    分支命名規則 /--
    例如:feature/issue427-marcus-new-user-status
    branch-type包含feature, release, bugfix, hotfix, try
    bugfix:修正版本的功能
    hotfix:修正以已上線版本的功能(有急迫性/嚴重Bug 會導致系統無法正常使用)
    try:可能是新技術的嘗試,不用於正式開發(可不寫issue,不能發pull request到其他分支,使用完畢就刪除)

  2. 所有Commit結尾需加上 See #,這個目的是為了讓你在看Issue的時候可以關聯到所以相關的Commit紀錄

  3. 在分支上開發完成後,開發工程師需要開pull request
    左側藍色框內選擇目前開發完成的分支
    右側紅色框內選擇要合併的分支,按照規範一般是會選擇develop,但也可能有特殊狀況
    中間綠色框內是選擇左側分支後,平台自動帶入的分支Commit紀錄,基本上不刪減
    下方黃色框內選擇Reviewer,基本上是Simon or Marcus
    pull request由reviewer進行code review,reviewer approve之後,由建置pull request的人負責合併
    合併完成後請刪除合併的原分支,例如:將feature/issue427-marcus-new-user-status merge至develop之後,應將feature/issue427-marcus-new-user-status branch刪除
    https://ithelp.ithome.com.tw/upload/images/20200504/20126774oNibXOySKX.png

  4. 核心功能的Unit test,並非所有功能都要做,經由討論後決定,一般會用在主要、不常變更的功能上
    每個版本在發佈時應在Git當次版本上打印版本號的Tag

結論

剛開始用的時候其實滿不習慣的,主要是會覺得頗麻煩,但是特別在多人開發的情況下,透過Issue了解其他人到底做了什麼,每個地方到底是何時為了什麼目的而調整,優點肯定是大於缺點啊


圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言