修改代碼後保存本地
push 前先 pull 線上代碼
Git commit
fix: feat(0429留言下單): add 'graphiteWidth' option
提交的具體情況
| type（必需） | scope（可選） | subject（必需） | (可選) |
|---|---|---|---|
| 說明 commit 的類別 | 說明 commit 影響的範圍 | commit 的簡短描述 | 對本次 commit 的詳細描述 |
type用於說明 commit 的類別:
br: 此項特別針對 bug 號，用於向測試反饋 bug 列表的 bug 修改情況
**feat：**新功能（feature）
**fix：**修補 bug
**docs：**文檔（documentation）
style： 格式（不影響代碼運行的變動）
**refactor：**重構（即不是新增功能，也不是修改 bug 的代碼變動）
**test：**增加測試
**chore：**構建過程或輔助工具的變動
revert: feat(pencil): add ‘graphiteWidth’ option (撤銷之前的 commit)
scope用於說明 commit 影響的範圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
subject是 commit 的簡短描述，不超過 50 個字符。以動詞開頭，使用第一人稱現在時，比如 change，而不是 changed 或 changes。第一個字母小寫。結尾不加句號（.）
Body 部分是對本次 commit 的詳細描述，可以分成多行。
實例：
fix: 修改了某某某內容
feat: 新增了某某某內容
chore: 更新了某某某版本
Master
master 和 develop 分支都是主分支，主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的代碼中。
master 分支上存放的應該是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的代碼時，master 分支上的代碼會被更新。同時，每一次更新，都有對應的版本號標籤（TAG）。
Develop
develop 分支是保存當前最新開發成果的分支。通常這個分支上的代碼也是可進行每日夜間發佈的代碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。
當 develop 分支上的代碼已實現了軟件需求說明書中所有的功能，通過了所有的測試後，並且代碼已經足夠穩定時，就可以將所有的開發成果合併回 master 分支了。對於 master 分支上的新提交的代碼建議都打上一個新的版本號標籤(TAG),供後續代碼跟蹤使用
Release
從 develop 分支派生
必須合併回 develop 分支和 master 分支
release 分支是爲發佈新的產品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等等）。通過在 release 分支上進行這些工作可以讓 develop 分支空閒出來以接受新的 feature 分支上的代碼提交，進入新的軟件開發迭代週期。
當 develop 分支上的代碼已經包含了所有即將發佈的版本中所計劃包含的軟件功能，並且已通過所有測試時，我們就可以考慮準備創建 release 分支了。而所有在當前即將發佈的版本之外的業務需求一定要確保不能混到 release 分支之內（避免由此引入一些不可控的系統缺陷）。
成功的派生了 release 分支，並被賦予版本號之後，develop 分支就可以爲“下一個版本”服務了。所謂的“下一個版本”是在當前即將發佈的版本之後發佈的版本。版本號的命名可以依據項目定義的版本號命名規則進行。
Hotfix
從 master 分支派生
必須合併回 master 分支和 develop 分支
除了是計劃外創建的以外，hotfix 分支與 release 分支十分相似：都可以產生一個新的可供在生產環境部署的軟件版本。當生產環境中的軟件遇到了異常情況或者發現了嚴重到必須立即修復的軟件缺陷的時候，就需要從 master 分支上指定的 TAG 版本派生 hotfix 分支來組織代碼的緊急修復工作。
Feature
從 develop 分支發起 feature 分支
代碼必須合併回 develop 分支
feature 分支（有時也可以被叫做“topic 分支”）通常是在開發一項新的軟件功能的時候使用，這個分支上的代碼變更最終合併回 develop 分支或者乾脆被拋棄掉（例如實驗性且效果不好的代碼變更）。
一般而言，feature 分支代碼可以保存在開發者自己的代碼庫中而不強制提交到主代碼庫裏。
歷史分支
Gitflow 工作流使用 2 個分支來記錄項目的歷史。master 分支存儲了正式發佈的歷史，而 develop 分支作爲功能的集成分支。
功能分支(Feature)
feature 不是從 master 分支上拉出新分支，而是使用 develop 分支作爲父分支。當新功能完成時，合併回 develop 分支。新功能提交應該從不直接與 master 分支交互。
發佈分支(Release)
develop 分支上有了做一次發佈（或者說快到了既定的發佈日）的足夠功能，就從 develop 分支上 fork 一個發佈分支。新建的分支用於開始發佈循環，所以從這個時間點開始之後新的功能不能再加到這個分支上
這個分支只應該做 Bug 修復、文檔生成和其它面向發佈任務。一旦對外發布的工作都完成了，發佈分支合併到 master 分支並分配一個版本號打好 Tag。另外，這些從新建發佈分支以來的做的修改要合併回 develop 分支。
使用一個用於發佈準備的專門分支，使得一個團隊可以在完善當前的發佈版本的同時，另一個團隊可以繼續開發下個版本的功能。
維護分支(Hotfix)
維護分支或說是熱修復（hotfix）分支用於生成快速給產品發佈版本（production releases）打補丁，這是唯一可以直接從 master 分支 fork 出來的分支。修復完成，修改應該馬上合併回 master 分支和 develop 分支（當前的發佈分支），master 分支應該用新的版本號打好 Tag。
爲 Bug 修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發佈循環。你可以把維護分支想成是一個直接在 master 分支上處理的臨時發佈。
參考：https://www.jianshu.com/p/3c5e6d41cc16