版本管理規範
|
文件編寫中 |
|
先來一張典中典 |
分支生命週期
以上生命週期僅作參考，不同開發團隊可能有不同的規範，可自行靈活定義。
例如我們團隊在開發時，至少需要保證以下流程：
develop 分支和 hotfix 分支，必須從 master 分支檢出
由 develop 分支合併到 test 分支
功能測試無誤後，由 test 分支合併到 release 分支
UAT測試透過後，由 release 分支合併到 master分支
對於工作量小的功能開發（工時小於1天），可以直接在devolop 分支進行開發，否則由 develop 分支檢出 feature 分支進行開發，開發完後合併到develop 分支
develop 為開發環境分支，始終保持最新完成以及bug修復後的程式碼，用於前後端聯調。一般開發的新功能時，feature分支都是基於develop分支建立的。
開發新功能時，以develop為基礎建立feature分支。
分支命名時以 feature/ 開頭，後面可以加上開發的功能模組， 命名示例：feature/user_module、feature/cart_module
線上出現緊急問題時，需要及時修復，以master分支為基線，建立hotfix分支。修復完成後，需要合併到 master 分支和 develop 分支。
分支命名以hotfix/ 開頭的為修復分支，它的命名規則與 feature 分支類似
release 為預上線分支（預釋出分支），UAT測試階段使用。一般由 test 或 hotfix 分支合併，不建議直接在 release 分支上直接修改程式碼。
|
細分分支: Pre-SIT SIT UAT PROD 環境所有hotfix和feature首先上到Pre-SIT/SIT，cherry-pick到其他分支 |
在編寫文件時，應遵循正式、簡潔且易於理解的語言規範。文件不僅應具備專業性和準確性，還應確保內容清晰明瞭。
feat: 新增功能
fix: 修復bug
docs: 僅文件更改
style: 不影響程式碼含義的更改（空白、格式設定、缺失 分號等）
refactor: 既不修復bug也不新增特性的程式碼更改
perf: 改進效能的程式碼更改
test: 新增缺少的測試或更正現有測試
chore: 對構建過程或輔助工具和庫（如文件）的更改
除此之外，還有一些常用的型別：
delete：刪除功能或檔案
modify：修改功能
build：改變構建流程，新增依賴庫、工具等（例如webpack、gulp、npm修改）
test：測試用例的新增、修改
ci：自動化流程配置修改
revert：回滾到上一個版本
提交問題必須為同一類別
提交問題不要超過3個
提交的commit發現不符合規範，git commit --amend -m "新的提交資訊"或 git reset --hard HEAD 重新提交一次
|
.gitignore是一份用於忽略不必提交的檔案的列表，專案中可以根據實際需求統一.gitignore檔案，減少不必要的檔案提交和衝突，淨化程式碼庫環境。 |
下面提供一份通用配置，可自取：
|
Bash |
在Git中，README.md 檔案通常用來描述專案的概要、安裝和使用方法、貢獻指南等。它是專案的門面，幫助其他開發者理解和使用你的專案。下面是一個典型的 README.md 檔案結構示例：
|
Bash |