# 版本發布流程規范
## 1\. Git 分支管理
### 1.1 分支定義
* `master`**主分支**
`master`分支的代碼必須跟生產環境的代碼完全一致, 這個分支只能從`release`分支合并,不能在這個分支直接修改。
每次新建`fixbug-*`分支或`feature-*`分支,必須從最新的`master`分支上創建。每次`master`代碼更新要附加`Tag`。
* `release-*`**預發布分支**
預發布分支是從 Dev 分支上面分出來的,預發布結束以后,必須合并進`develop`和`master`分支。
預發布用于本次迭代任務發布,用于合并通過測試的`develop`分支。此分支目的用于匯總當期發版的分支及代碼 review。
* `develop`**開發分支**
提測用的分支,`fixbug-*`分支或`feature-*`分支 開發完后把分支推到遠程,然后合并到`develop`分支,代碼自動提交到測試服務器進行測試。
* `feature-*`**功能分支**
開發某種特定功能,從`Master`分支上面分出來的。開發完成后,要再并入`Develop`。可以采用`feature-*`的形式命名。
* `fixbug-*`**修復分支**
修補`bug分支`是從`Master`分支上面分出來的。修補結束以后,再合并進`master`和`develop`分支。它的命名,可以采用`fixbug-*`的形式。
### 1.2 develop 開發分支示例
創建開發分支
* `git checkout -b develop master`
develop 分支合并到 master 分支
* `git checkout master`
* `git merge --no-ff develop`
### 1.3 feature 功能分支示例
創建功能分支
* `git checkout -b feature-x develop`
合并功能分支到開發分支
* `git checkout develop`
* `git merge --no-ff feature-x`
刪除功能分支
* `git branch -d feature-x`
### 1.3 fixbug 修復 bug 分支示例
創建一個修補 bug 分支
* `git checkout -b fixbug-0.1 master`
修補結束后,合并到 master 分支
* `git checkout master`
* `git merge --no-ff fixbug-0.1`
* `git tag -a 0.1.1`
再合并到 dev 分支
* `git checkout develop`
* `git merge --no-ff fixbug-0.1`
最后,刪除”修補 bug 分支”
* `git branch -d fixbug-0.1`
## Reference
* [團隊項目的 Git 分支管理規范](https://www.cnblogs.com/spec-dog/p/11043371.html "https://www.cnblogs.com/spec-dog/p/11043371.html")
* [Git 分支命名規范(完)](https://blog.csdn.net/qq_33858250/article/details/81047883 "https://blog.csdn.net/qq_33858250/article/details/81047883")
- 視覺規范
- 色彩
- 文字
- 偏移
- 圖標
- 列表組件
- 表單組件
- 詳情組件
- 其他組件
- 研發規范
- 編碼規范
- 函數式編程
- 純函數
- 柯里化
- 函數組合
- 函子
- 面向對象編程
- 設計原則
- 單一職責原則
- 里氏替換原則
- 依賴倒置原則
- 接口隔離原則
- 開閉原則
- 迪米特原則
- 組合復用原則
- 設計模式
- 創建型模式
- 工廠模式
- 簡單工廠
- 工廠方法
- 抽象工廠
- 單例模式
- 建造者模式
- 原型模式
- 結構型模式
- 適配器模式
- 橋接模式
- 過濾器模式
- 組合模式
- 裝飾器模式
- 外觀模式
- 享元模式
- 代理模式
- 行為型模式
- 責任鏈模式
- 命令模式
- 解釋器模式
- 迭代器模式
- 中介者模式
- 備忘錄模式
- 觀察者模式
- 狀態模式
- 策略模式
- 模板模式
- 訪問者模式
- 組件設計規范
- 組件文檔編寫規范
- 版本管理規范