git規(guī)范

1.概覽

項(xiàng)目默認(rèn)分支為線上 master 預(yù)發(fā)布 develop
commit信息必須完整描述修改內(nèi)容
commit之前必須進(jìn)行pull或者fetch進(jìn)行同步
所有需求建立新分支進(jìn)行修改
develop 分支作為開發(fā)階段主分支各需求負(fù)責(zé)人本地建立新分支進(jìn)行修改修改完成后使用rebase合并冗余commit信息合并至develop分支

2.commit規(guī)范

保證commit盡量只做一件事
書寫commit message言簡意賅
規(guī)范commit message格式

完整commit信息大致如下參考 Angular Git Commit Guidelines ：

						
							# 標(biāo)題行：50個字符以內(nèi)，描述主要變更內(nèi)容 # # 主體內(nèi)容：更詳細(xì)的說明文本，建議72個字符以內(nèi)。 需要描述的信息包括: # # * 為什么這個變更是必須的?
							它可能是用來修復(fù)一個bug，增加一個feature，提升性能、可靠性、穩(wěn)定性等等 # * 他如何解決這個問題? 具體描述解決問題的步驟 # *
							是否存在副作用、風(fēng)險(xiǎn)? # # 如果需要的化可以添加一個鏈接到issue地址或者其它文檔

						
							<type>: <subject> <BLANK LINE> <body> <BLANK
							LINE> <footer> type: 本次 commit 的類型，諸如 bugfix docs style 等 scope:
							本次 commit 波及的范圍 subject: 簡明扼要的闡述下本次 commit 的主旨，結(jié)尾無需標(biāo)點(diǎn) body: 主體內(nèi)容 footer:
							描述下與之關(guān)聯(lián)的 bug 或者需求鏈接

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

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

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

3. 分支規(guī)范

一個穩(wěn)定 master 分支
一個待發(fā)布的 develop 分支
若干個正在開發(fā)的 feature 分支
- 依據(jù)需求進(jìn)行建立由各實(shí)際負(fù)責(zé)人進(jìn)行建立，需求關(guān)閉后刪除
- 如遇到線上有十分嚴(yán)重bug，應(yīng)在master上切換出hotFix分支進(jìn)行bug修復(fù)，并驗(yàn)證好了后隨即合并到master上準(zhǔn)備發(fā)布
- 如遇到線上有一般的bug，可在develop上切換出hotFix分支進(jìn)行bug修復(fù)，完成后合并到develop上，等下次版本一起發(fā)布
分支合并前若有必要先 rebase 待合并的分支
合并到 develop 中必須去除調(diào)試commit信息確保主分支commit信息的純凈
如非必須情況禁止將 feature 分支push 至origin中允許情況如下：
- 除實(shí)際負(fù)責(zé)人之外需其余團(tuán)隊(duì)成員配合
- 本地環(huán)境無法滿足測試情況

4. 操作規(guī)范

禁止使用 git push --force 進(jìn)行提交
禁止在 develop master 分支使用 rebase 操作， rebase 僅可在無合作者的 feature 中進(jìn)行
分支合并出現(xiàn)沖突必須解決后才能提交，禁止直接撤銷修改后push
合作分支 commit 之前需先 fetch 或 pull 進(jìn)行更新

git規(guī)范 #

1.概覽 #

2.commit規(guī)范 #

3. 分支規(guī)范 #

4. 操作規(guī)范 #

git規(guī)范

1.概覽

2.commit規(guī)范

3. 分支規(guī)范

4. 操作規(guī)范