什麼是以發行為基礎的工作流程？
在這裡，我們會討論如何使用 GitHub 建立以發行為基礎的工作流程。
什麼是以發行為基礎的工作流程？
以發行為基礎的工作流程是一組模式與原則，其著重於「發行軟體」。 雖然這種概念看起來可能像是開發小組的明顯目標，但這種觀點的價值更加微妙。 在本單元中，我們會討論其如何驅使發行週期的三個不同部分：管理專案、選取分支策略，並發行給客戶。
使用 GitHub 專案版面進行規劃
就規劃的思維而言，以發行為中心表示問題會分成將產生新版本的不同反覆項目。 這些反覆項目通常稱為「短期衝刺」，而且會以大致相同的週期進行時間封裝，以產生增量變更。 其他小組偏好將整個發行版本封裝成可持續數個月或更久時間的單一反覆項目。 在 GitHub 中，會將這些反覆項目當做專案來管理。
專案的主要功能是其版面。 版面是反覆項目記錄的集中方案，而且包含要解析的所有卡片。 卡片可以代表問題、提取要求，甚至只是一般記事。
根據預設，每張卡片都會在 [待辦事項] 欄開始，並在工作開始之後移至 [進行中] ，最後結束於 [完成]。 您可以自訂這些欄、新增其他欄，或將自動化套用到這些卡片與其屬性的移動，以符合您小組的程序。
深入了解如何管理專案版面 \(英文\)。
卡片的專案狀態會整合到存放庫。 例如，將卡片從 [待辦事項] 拖曳到 [進行中] 會變更其狀態，以及更新專案標題旁的視覺效果指示器。 綠色區段表示標示為 [完成] 的卡片部分，而紫色則用於 [進行中] 的卡片。 剩餘的空間代表尚未開始的卡片數量。 除了在版面周圍拖曳卡片之外，您也可以從主要檢視加以更新。
當您使用專案版面時，所有專案關係人都可以輕鬆地了解專案的狀態與速度。 您也可以建立範圍為個別使用者或組織所擁有之存放庫集合的版面。
深入了解如何使用專案版面來追蹤工作進度 \(英文\)。
追蹤特定里程碑
針對小組或可能的小組子集，GitHub 提供里程碑追蹤。
里程碑與專案追蹤相似之處在於強調問題與提取要求的優先順序完成。 不過，專案可能會著重在小組的程序上，而里程碑則著重於產品。
深入了解如何使用里程碑來追蹤工作進度 \(英文\)。
選取分支策略
有多個開發人員平行工作的存放庫需要定義完善的分支策略。 在專案初期安排一種統一的方法，可減少小組與程式碼基底規模的混淆與挫折。
GitHub 流程
除了提供共同作業軟體開發的平台，GitHub 也提供規定的工作流程，此工作流程的設計旨在最佳化其各種使用功能。 雖然 GitHub 可以與幾乎任何軟體開發程序搭配使用，但如果您的小組尚未安排好程序，建議您考慮 GitHub 流程 \(英文\)。
使用長時間執行的分支
長時間執行的分支是永遠不會刪除的 Git 分支。 有些小組會完全避免加以使用，而改為使用短時間執行的分支與錯誤 (Bug) 修正分支。 針對那些小組，任何努力的目標就是產生提取要求，將其工作合併回 main。 對於永遠不需要回頭查看的專案 (例如不支援先前版本的第一方 Web 應用程式) 而言，這種方法十分有效。
不過，在某些情況下，長期執行的分支可滿足小組的最大利益。 針對長時間執行的分支而言，最常見的情況是當必須在一段較長的時間支援產品的多個版本時。 當小組需要為這種承諾進行規劃時，存放庫應遵循標準慣例，例如 release-v1.0與 release-v2.0 等等。 那些分支也應該在 GitHub 中標示為受保護，以便寫入權限受到控制，而且不會遭意外刪除。
小組仍應將 main 維護為根分支，並向上游合併其發行分支變更，只要它們符合專案的未來。 當時間到來時，release-v3.0 應該以 main 為基礎，讓 release-v2.0 的服務工作不會使存放庫變得複雜。
維護長時間執行的分支
假設錯誤 (Bug) 修正已合併至 release-v2.0 分支，然後再次向上游合併到 main。 之後，您發現此錯誤 (Bug) 也存在於 release-v1.0 分支中，而且需要為仍在使用該版本的客戶向後移植修正程式。 向後移植此修正程式的最佳方式為何？
將 main 分支向下合併到 release-v1.0 不是可行的選項，因為其會包含許多不打算屬於該版本的認可。 基於相同的理由，將 release-v1.0 重定基底到目前的 main 認可並不是可行選項。
另一個選項是在 release-v1.0 分支上手動重新實作修正，但該方法需要重寫，而且將無法在多個版本之間妥善擴縮。 不過，Git 會以其 cherry-pick 命令的形式，提供此問題的自動化解決方案。
什麼是 Git 的 cherry-pick 命令？
git cherry-pick 是一個命令，可讓您將來自某個分支的特定認可套用到另一個分支。 其只會逐一查看選取的認可，並將那些認可套用到目標分支作為新的認可。 如有需要，開發人員可以在完成向後移植之前合併任何衝突。
深入了解 Git 的 cherry-pick \(英文\)。
發行給取用者
當產品版本準備好要發行時，GitHub 會簡化封裝及通知取用者的程序。
建立版本就像填寫表單一樣簡單：
- 輸入要套用的 Git 標記，這應該遵循語意化版本控制系統，例如
v1.0.2。 GitHub 會管理建立您指定之 Git 標記的程序。 - 輸入您的版本名稱。 一些常見的作法是：
- 使用描述性名稱
- 使用 Git 版本
- 使用此版本自上一版以來變更的簡要摘要
- 使用代號名稱或隨機片語
- 提供版本資訊。 您可以透過 Release Drafter 應用程式將此工作自動化，此應用程式會分析自前一版以來的變更，並包含相關聯的提取要求標題。
- 如果您想要提供檔案做為發行的一部分 (例如預先建置的安裝程式)，您可以將它們拖放到表單上。 您不需要封裝來源，因為 GitHub 會自動為您處理。
- 核取該方塊，以指出版本是否為發行前版本。 此指示可協助客戶避免使用發行前版本 (如果他們想要)。
發行版本後，監看存放庫的每個人都會收到通知。
深入了解 GitHub 版本 \(英文\)。