分支規範¶

在敏捷攀術團隊中分支建立是依照

• A successful Git branching model
• 「語意化版本 2.0.0」(Semantic Versioning 2.0.0)
• RFC 2119

建立，其原因是與用法可以參考

• Git Flow 是什麼?為什麼需要這種東西?
• Using git-flow to automate your git branching workflow
• git-flow 備忘清單

基本會以上述連結來做分支運用的規範，但其中有詳細運作規範會在下面詳細提出，如果認為有更好的方式可以在「議題」(Issues)提出想法。

目錄¶

• 分支規範
• 目錄
• 分支
  • master
  • develop
  • feature
  • release
  • hotfix
• 變更基礎版本

分支¶

依照Git-Flow的規範中會有以下五條分支:

• master
• develop
• feature
• release
• hotfix

在Git-Flow會有主要分支master與develop，develop是從master分出來的，並且所有的修改與變更都要在develop上變更所有的修改與開發，當通過審查後併回master，這樣的好處是讓開發與穩定版本是分開，適合在有內部與公開同時開發的團隊。

master¶

master分支用於發佈確定、沒問題以及功能完整的版本，在通過敏捷攀樹團隊與社群合併的時候會經過檢查與確認，當通過檢查時會搭配「標籤」(Tag)、「語意化版本 2.0.0」(Semantic Versioning 2.0.0)使用，為每一次的發佈做標記。

例如用在敏捷攀樹手冊上代表了目前手冊內容是目前敏捷攀樹團隊認為可以發佈的內容，可以用在實際的攀樹、教學以及課程，前期可能還會有很多遺漏的地方，但相信會一直隨著時間而修正符合時代的需求。

在未來快速的組織活動團隊時，會詢問是用哪一版本的手冊，確保團隊間可以在相同共識下協作，詳細的「標籤」(Tag)、「語意化版本 2.0.0」(Semantic Versioning 2.0.0)使用方式請查閱版本規範。

develop¶

develop用於提供feature分支所變更造成開發上的改變，此分支名稱不會因為誰使用而改變，與master一樣保持存在的分支，由於不想要影響到master的穩定性，因此使用develop解決這個問題。

用在專案上代表了目前專案內容是目前由團隊與社群共同努力協作改進的分支。

feature¶

feature分支用於修改、增加與開發使用，所有的功能開發、修訂項目與變更內容都「必須」(MUST)使用此來開發，開分支的時候「必須」(MUST)從develop開新分支，其命名規範如下:

feature/username/Issue-Branch.or_Summary

從左到右代表:

• feature代表了是修改分支的意思，所有新增功能、修訂項目與變更內容都「必須」(MUST)在此類型分支修改
• /是階層分隔，「必須」(MUST)在feature後面放入
• username代表了分支的擁有者，擁有者使用GitHub/GitLab使用者帳號代表
• /是階層分隔，「必須」(MUST)在username後面放入
• Issue代表了「議題」(Issues)的代號
• -代表了「議題」(Issues)與「分支摘要」(Branch Summary)的連接性與區隔，「必須」(MUST)使用
• Branch.or_Summary用於註解分支的用途，簡單的描述修改內容的摘要，其命名規則如下:
  • 「必須」(MUST)使用英文大小寫
  • 「禁止」(MUST NOT)使用逗號、空白
  • 空白「可」(SHOULD)使用.或_使用，「禁止」(MUST NOT)使用-來做空白區隔
  • 整個分支名稱「必須」(MUST)在72個英文字母內

在「拉請求」(Pull Repuests)合併前請從develop取得最新的基礎版本，請參閱變更基礎版本。

release¶

當某像功能在開發出來後需要經過驗證、測試並發佈的時候，此時「必須」(MUST)從develop開出新的分支提供團隊驗證與檢查，驗證、測試與檢查時會搭配「標籤」(Tag)、「語意化版本 2.0.0」(Semantic Versioning 2.0.0)與「軟體版本週期」(Software release life cycle)使用，當通過驗證、測試與檢查的時候，會將此分支併入master，命名規則如下:

release/vX.X.X-Summary

從左到右:

• release代表此分支是大家覺得develop的修改可以發佈了，但需要通過驗證
• /是階層分隔，「必須」(MUST)放在release後面放入
• vX.X.X是預計下一個版本，會與「標籤」(Tag)上顯示的一樣
• -代表了「版本」與「版本摘要」(Semantic Summary)的連接性與區隔，「必須」(MUST)使用
• Summary
  • 「必須」(MUST)使用英文大小寫
  • 「禁止」(MUST NOT)使用逗號、空白
  • 空白可以使用.或_使用，「禁止」(MUST NOT)使用-來做空白區隔
  • 整個分支名稱「必須」(MUST)在72個英文字母內

當此分支出來的時候，如果要修正release中需要修正的內容時，「必須」(MUST)透過develop的修正後在合併，此時如果有其他不關此發佈的內容，會透過git cherry-pick的方式將所指定的版本做放入的動作，來持續讓develop修改。

詳細的「標籤」(Tag)、「語意化版本 2.0.0」(Semantic Versioning 2.0.0)與「軟體版本週期」(Software release life cycle)使用方式請查閱版本規範。

在專案中此分支代表了專案每一次的進步，希望改變可以在持續的更新下不斷改進，達到持續整合持續佈署的目標。

hotfix¶

hotfix分支用於修復錯誤、安全漏洞與安全性，使用時「必須」(MUST)從master分支出來為穩定的版本做修復，在修正錯誤後分支要轉成release分支驗證後發佈一個版本後同時併入master與develop，命名規則如下:

hotfix/username/Issue-Branch.or_Summary

從左到右代表:

• hotfix代表了是修復分支的意思
• /是階層分隔，「必須」(MUST)在hotfix後面放入
• username代表了分支的擁有者，擁有者使用GitHub/GitLab使用者帳號代表
• /是階層分隔，「必須」(MUST)在username後面放入
• Issue代表了針對修復的「議題」(Issues)代號
• -代表了「議題」(Issues)與「分支摘要」(Branch Summary)的連接性與區隔，「必須」(MUST)使用
• Branch.or_Summary用於註解分支的用途，簡單的描述修改內容的摘要，其命名規則如下:
  • 「必須」(MUST)使用英文大小寫
  • 「禁止」(MUST NOT)使用逗號、空白
  • 空白「可」(SHOULD)使用.或_使用，「禁止」(MUST NOT)使用-來做空白區隔
  • 整個分支名稱「必須」(MUST)在72個英文字母內

變更基礎版本¶

在「拉請求」(Pull Repuests)合併前為了避免出現 基礎版本不一致 、 開發線雜亂 等問題，例如使用feature修改功能完成後「拉請求」(Pull Repuests)，「拉請求」(Pull Repuests)前「必須」(MUST)使用git rebase develop來將你的feature從develop取得最新的版本變成分支的基礎版本，我們稱作為「變更基礎版本」(Re Base)。