[Git Flow and Release Process](https://sap.github.io/spartacus-docs/git-flow-and-releases/#page-title)

# Library Version Compatibility

Spartacus 專案由一組庫組成。 為了更容易知道哪個版本的庫與另一個版本相容，庫版本在所有包之間同步。 這意味著當我們要釋出 1.5.0 版本時，我們會發布此版本下的所有庫，即使某些庫自上一版本以來沒有任何更改。 這樣做時，我們可以使用單個版本號來引用任何給定版本的整個 Spartacus 庫集。

這也意味著您可以確信，如果您安裝所有具有相同版本的軟體包，那麼一切都將正常工作。 不同版本的庫可以很好地協同工作，但我們不會測試這些配置，也不能保證正確的行為。

# version support

對於版本控制，我們遵循語義版本控制，也稱為 SemVer。 除了穩定版本，Spartacus 還生產 next 和 rc 版本。

我們對版本的假設如下：

* Stable 版本是經過良好測試的 Spartacus 版本（包括社群測試），並且只會修補錯誤。這些版本在 npm 上的最新標籤下可用。

* 當 Spartacus 團隊完成該版本所有新功能的開發後，就會釋出一個 rc 版本，這意味著功能和公共 API 不會有任何重大變化。社群可以安全地開始測試 rc 版本中的功能。 rc 版本可能包含一些錯誤，這些錯誤將在穩定版本釋出之前修復。當沒有更多錯誤並且社群停止報告該版本的問題時，我們會繼續製作穩定版本。

* 當 Spartacus 團隊完成特定功能時，將釋出一個 next 版本。這允許社群立即開始測試該功能。這些 next 版本可能包含很多錯誤，功能和公共 API 可能仍會發生變化。如果您想盡快測試新功能，這是適合您的版本。下一個版本在 npm 上的 next 標籤下可用。

注意：強烈建議您不要在生產設定中使用 next 版本。這是因為從next 版本升級可能比從一個穩定版本升級到另一個要困難得多。

# Support Policy

始終支援至少一個穩定或 rc 版本。

一旦版本 x.y 釋出，它將被積極維護，直到版本 x.z 的新穩定版或 rc 釋出。 屆時，版本 x.z 將成為積極維護的版本，下一個版本的工作將開始。

例如，假設我們剛剛釋出了 1.5.0-rc.0 版本。 從那時起，將積極維護 1.5.x 版本，直到我們釋出 1.6.0-rc.0。 一旦 1.6.0-rc.0 版本釋出，我們就會將主動支援切換到 1.6.x 版本。

注意：對於重要的安全問題或關鍵的錯誤修復，可能會有針對不再積極維護的版本的附加補丁。

# Git Flow

Spartacus 專案中的流程圍繞前面部分中描述的版本支援構建。

develop 分支是預設分支，用於新版本開發，包括次要和主要版本。 所有功能和錯誤修復都合併到這個分支。

還有一個 maintenance 分支，它隨著新的穩定版或 rc 版本而變化，用於補丁版本。 只有錯誤修復合併到 maintenance 分支。

一旦我們釋出了 1.4.0-rc.0 版本，release/1.4.x 分支將被視為維護分支。 當我們釋出 1.5.0-rc.0 版本時，則 release/1.5.x 分支成為維護分支，依此類推。

其他分支約定：

* feature/GH-xxxx 分支用於簡單的功能和錯誤修復
* epic/epic-name 分支用於大特徵（稱為 epics）
* release/1.4.0-rc.0 分支用於特定的釋出（你可以將它們與維護分支區分開來，因為包含完整的版本號）

# Flow for Epic Development

* 從 develop 分支建立一個新的 epic/epic-name分支。

* 從epic/epic-name 為epic 子任務建立分支，並將它們合併回 epic/epic-name 分支。

* 不時地使用來自 develop 分支的更改更新您的 epic/epic-name 分支（它將幫助您管理衝突）。

* 當 epic 完成時，建立一個 PR 並將 epic/epic-name 分支合併到 develop 分支。

# Flow for Smaller Features

* 從 develop 分支建立一個新的 feature /GH-xxxx 分支。

* 開發您的功能。

* 完成後，建立一個 PR 並將 feature/GH-xxxx 分支合併到 develop 分支。

# 錯誤修復流程

以下是處理錯誤修復的步驟：

* 從開發分支建立一個新的 feature/GH-xxxx 分支。

* 修復錯誤。

* 建立 PR 並將 feature/GH-xxxx 分支合併到 develop 分支。

* 如果此修復適用於積極支援的版本，請從 maintenance 分支建立一個新的 feature/GH-xxxx-maintenance 分支。

* Cherry pick the commit with the fix from the develop branch.

* 建立 PR 並將 feature/GH-xxxx-maintenance 合併到 maintenance 分支中。

# Terminology

以下是我們目前使用的可能會產生誤導的術語：

“feature freeze” 描述了我們完成了新的次要或主要版本的所有功能的那一刻（這意味著我們希望很快釋出一個 rc，但仍需要修復一些錯誤）。

“code freeze” 描述了我們停止提交程式碼的那一刻（儘管這在我們的流程中不是必需的，因為我們總是可以切斷髮布或維護分支並繼續提交）。

以下概念可用於替換這些術語：

我們可以建立一個新的維護分支併釋出一個新的 rc。 第一個 RC 可能有問題，因為 rc 版本可能包含錯誤是公認的。

我們可以建立一個新的 release 分支，而不是凍結程式碼。 我們永遠不需要阻塞主要的開發或維護分支（我們不需要用這些細節來打擾開發人員，因為我們的流程支援在這些分支上併發工作併發布另一個版本）。

# term：維護分支，特性分支

maintenance 分支是需要合併到release/xxx的東西

示例：你合併了一些東西來開發，但它需要在 4.0.1 中或者也需要向後移植到另一箇舊的釋出分支，然後你需要建立一個 PR 來將它合併到 release/4.0.x 。

通常，新功能維護分支最終是 feature/GH-xxx-maintenance 並將合併到 release/xxx 而不是 develop。

SAP Spartacus 的 git flow 和釋出流程

相關文章