SAP Spartacus 的 git flow 和釋出流程

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。