git規范

1.概覽

  • 項目默認分支為 線上 master 預發布 develop

  • commit信息 必須 完整描述修改內容

  • commit之前 必須 進行pull或者fetch進行同步

  • 所有需求建立新分支進行修改

  • develop 分支作為開發階段主分支 各需求負責人本地建立新分支進行修改 修改完成后使用rebase合并冗余commit信息合并至develop分支

2.commit規范

  • 保證commit盡量只做一件事
  • 書寫commit message言簡意賅
  • 規范commit message格式
  1. 完整commit信息大致如下 參考 Angular Git Commit Guidelines ： 
						
							# 標題行：50個字符以內，描述主要變更內容 # # 主體內容：更詳細的說明文本，建議72個字符以內。 需要描述的信息包括: # # * 為什么這個變更是必須的?
							它可能是用來修復一個bug，增加一個feature，提升性能、可靠性、穩定性等等 # * 他如何解決這個問題? 具體描述解決問題的步驟 # *
							是否存在副作用、風險? # # 如果需要的化可以添加一個鏈接到issue地址或者其它文檔
						
						
					
						
							<type>: <subject> <BLANK LINE> <body> <BLANK
							LINE> <footer> type: 本次 commit 的類型，諸如 bugfix docs style 等 scope:
							本次 commit 波及的范圍 subject: 簡明扼要的闡述下本次 commit 的主旨，結尾無需標點 body: 主體內容 footer:
							描述下與之關聯的 bug 或者需求鏈接

  1. 開發過程中遇到單行無法完整描述commit信息時 必須 使用完整commit信息提交

  2. commit信息開頭 必須 指明此次提交類型 包括但是不限于以下幾種： 

    								
									feat: 添加新特性 update: 因需求 添加了新的邏輯 作為feat的備選方案，僅在去除一些邏輯時使用 fix: 修復bug docs:
									僅修改了文檔 style: 僅代碼格式調整 refactor: 代碼重構，沒有加新功能或者修復bug delete: 文檔或代碼的刪除，沒有功能修改或者修復bug

3. 分支規范

  • 一個穩定 master 分支

  • 一個待發布的 develop 分支

  • 若干個正在開發的 feature 分支

    • 依據需求進行建立 由各實際負責人進行建立，需求關閉后 刪除
    • 如遇到線上有十分嚴重bug，應在master上切換出hotFix分支進行bug修復，并驗證好了后隨即合并到master上準備發布
    • 如遇到線上有一般的bug，可在develop上切換出hotFix分支進行bug修復，完成后合并到develop上，等下次版本一起發布

  • 分支合并前若有必要先 rebase 待合并的分支

  • 合并到 develop 中 必須 去除調試commit信息 確保主分支commit信息的純凈

  • 如非必須情況 禁止 將 feature 分支push 至origin中 允許情況如下：

    • 除實際負責人之外需其余團隊成員配合
    • 本地環境無法滿足測試情況

4. 操作規范

  • 禁止 使用 git push --force 進行提交

  • 禁止 在 develop master 分支使用 rebase 操作， rebase 僅可在無合作者的 feature 中進行

  • 分支合并出現沖突 必須 解決后才能提交， 禁止 直接撤銷修改后push

  • 合作分支 commit 之前需先 fetch 或 pull 進行更新