Git-Bash 最佳指引手冊
每個人都應當遵循對於分支命名、標記和編碼的規範。每個組織都有自己的規範或者最佳實踐，並且很多建議都可以從網上免費獲取，而重要的是儘早選擇合適的規範並在團隊中遵循。
概述
-
DEV 環境 用於開發者除錯使用。
-
UAT 環境 使用者驗收測試環境，用於生產環境下的軟體測試者測試使用。
-
FAT 環境 功能驗收測試環境，用於測試環境下的軟體測試者測試使用。
-
PRO 環境 生產環境。
-
專案域名為：http://www.jinmaocloud.com，相關環境的域名可這樣配置：
DEV 環境：本地配置虛擬域名即可 FAT 環境：http://fat.jinmaocloud.com UAT 環境：http://uat.jinmaocloud.com PRO 環境：http://www.jinmaocloud.com
分支
| 分支 | 名稱 | 環境 | 可訪問 |
|---|---|---|---|
| master | 主分支 | PRO | 是 |
| release | 預上線分支 | UAT | 是 |
| hotfix | 緊急修復分支 | DEV | 否 |
| develop | 測試分支 | FAT | 是 |
| feature | 需求開發分支 | DEV | 否 |
master 分支
- master 為主分支，用於部署到正式環境（PRO），一般由 release 或 hotfix 分支合併，任何情況下不允許直接在 master 分支上修改程式碼。
release 分支
-
release 為預上線分支，用於部署到預上線環境（UAT），始終保持與 master 分支一致，一般由 develop 或 hotfix 分支合併，不建議直接在 release 分支上直接修改程式碼。
-
如果在 release 分支測試出問題，需要回歸驗證 develop 分支看否存在此問題。
hotfix 分支
- hotfix 為緊急修復分支，命名規則為 hotfix- 開頭。
當線上出現緊急問題需要馬上修復時，需要基於 release 或 master 分支建立 hotfix 分支，修復完成後，再合併到 release 或 develop 分支，一旦修復上線，便將其刪除。
develop 分支
- develop 為測試分支，用於部署到測試環境（FAT），始終保持最新完成以及 bug 修復後的程式碼，可根據需求大小程度確定是由 feature 分支合併，還是直接在上面開發。
一定是滿足測試的程式碼才能往上面合併或提交。
feature 分支
- feature 為需求開發分支，命名規則為 feature- 開頭，一旦該需求上線，便將其刪除。
這麼說可能有點不容易理解，接下來舉幾個開發場景。
開發場景
新需求加入
有一個訂單管理的新需求需要開發，首先要建立一個 feature-order 分支，問題來了，該分支是基於哪個分支建立？
如果 存在 未測試完畢的需求，就基於 master 建立。
如果 不存在 未測試完畢的需求，就基於 develop 建立。
需求在 feature-order 分支開發完畢，準備提測時，要先確定 develop 不存在未測試完畢的需求，這時研發人員才能將將程式碼合併到 develop （測試環境）供測試人員測試。
-
測試人員在 develop （測試環境） 測試通過後，研發人員再將程式碼釋出到 release （預上線環境）供測試人員測試。
-
測試人員在 release （預上線環境）測試通過後，研發人員再將程式碼釋出到 master （正式環境）供測試人員測試。
-
測試人員在 master (正式環境) 測試通過後，研發人員需要刪除 feature-order 分支。
普通迭代
有一個訂單管理的迭代需求，如果開發工時 < 1 天，直接在 develop 開發，如果開發工時 > 1 天，那就需要建立分支，在分支上開發。
開發後的提測上線流程 與 新需求加入的流程一致。
修復測試環境 Bug
在 develop 測試出現了 Bug，如果修復工時 < 2h，直接在 develop 修復，如果修復工時 > 2h，需要在分支上修復。
修復後的提測上線流程 與 新需求加入的流程一致。
修改預上線環境 Bug
在 release 測試出現了 Bug，首先要回歸下 develop 分支是否同樣存在這個問題。
如果存在，修復流程 與 修復測試環境 Bug 流程一致。
如果不存在，這種可能性比較少，大部分是資料相容問題，環境配置問題等。
修改正式環境 Bug
在 master 測試出現了 Bug，首先要回歸下 release 和 develop 分支是否同樣存在這個問題。
如果存在，修復流程 與 修復測試環境 Bug 流程一致。
如果不存在，這種可能性也比較少，大部分是資料相容問題，環境配置問題等。
緊急修復正式環境 Bug
需求在測試環節未測試出 Bug，上線執行一段時候後出現了 Bug，需要緊急修復的。
我個人理解緊急修復的意思是沒時間驗證測試環境了，但還是建議驗證下預上線環境。
-
如果 release 分支存在未測試完畢的需求，就基於 master 建立 hotfix-xxx 分支，修復完畢後釋出到 master 驗證，驗證完畢後，將 master 程式碼合併到 release 和 develop 分支，同時刪掉 hotfix-xxx 分支。
-
如果 release 分支不存在未測試完畢的需求，但 develop 分支存在未測試完畢的需求，就基於 release 建立 hotfix-xxx 分支，修復完畢後釋出到 release 驗證，後面流程與上線流程一致，驗證完畢後，將 master 程式碼合併到 develop 分支，同時刪掉 hotfix-xxx 分支。
-
如果 release 和 develop 分支都不存在未測試完畢的需求， 就直接在 develop 分支上修復完畢後，釋出到 release 驗證，後面流程與上線流程一致。
檢出程式碼的姿勢
檢出遠端倉庫
- git clone https://github.com/jmyf/Git-Bash.git
可以檢出 origin/main 分支到本地，這是 GitHub 建立倉庫時預設的 主機名/分支名。使用 git branch -vv 檢視本地分支狀態
本地分支名為 main，關聯的遠端分支名為 origin/main（origin 是主機名，main 是分支名
檢出遠端分支
- 一個專案需要新建很多遠端分支，以便於並行開發
同步遠端分支
檢出遠端分支
提交程式碼的姿勢
永遠不要在一個本地分支上，連續提交程式碼。在多人協作的情況下，這會導致每筆提交之間存在依賴關係，進而可能導致 merge 衝突、cherry-pick 合入冗餘程式碼。
-
暫存程式碼
git stash save [-u] 'update readme.md'
[-u] 表示引數可選，加 -u 會將本地新增檔案也暫存，不加則僅暫存本地修改部分。'update readme.md' 為描述，下面列出 git stash 支援的所有操作：
- git stash list 顯示所有暫存記錄
- git stash show stash@{0} 檢視指定的暫存記錄
- git stash pop stash@{0} 彈出指定的暫存記錄
- git stash drop stash@{0} 刪除指定的暫存記錄
- git stash clear 清空暫存記錄
-
同步程式碼
git pull --rebase
-
彈出暫存程式碼
git stash pop [stash@{0}]
[stash@{0}] 表示可選，不加預設彈出棧頂元素，也可以指定彈出哪一個暫存記錄。彈出結果如下：
-
新建本地分支
根據不同功能新建不同的本地分支，比如 feature_shopping，bugfix_tombstone 等等，假設我們現在需要實現一個購物功能，我們應該使用 git checkout -b feature_shopping 新建一個本地分支來實現這個需求：
- 提交程式碼
git commit -m "update README.md" 表示將修改提交到本地倉庫，此時還沒有推送到遠端倉庫。-m 後面的是修改描述，這是一種簡便寫法。
- 追加提交
commit 之後，本地又修改了一些檔案，此時需要使用 git commit --amend 追加提交：
- 回退提交
commit 之後，發現提交多了，把不需要提交的也提交了，此時需要回退，有兩種方式：
git reset [--soft] commit_id，軟回退，不會丟棄檔案修改記錄，--soft 不加也可以。
git reset --hard commit_id，硬回退，丟棄所有修改。一般僅在需要回退到指定節點驗證問題時使用。
檢視 commit_id：
git log -1
-1 表示只檢視提交記錄裡的最後一條：
輸入 git reset 22d92a412e7ed6e72ee2107db891e7571d307c81，即可回退提交。然後重新 git add
- 推送程式碼
commit 之後很多人就直接 git push 了，這是不對的，應當先同步程式碼。由於我們現在在新建的本地分支 feature_shopping 上，這個分支沒有關聯遠端分支，所以無法也不應該使用 git pull --rebase 來同步程式碼。正確的操作為：
git checkout master：切到本地主分支
git pull --rebase：同步程式碼
git checkout feature_shopping：切換到本地需求分支
git rebase master：將本地主分支程式碼，合入到本地需求分支（可能有衝突，按照 Git 的提示修復即可）
git push origin HEAD:refs/for/master：將本地需求分支的提交推送到遠端 master 分支