Git Flow and Release Process

Library Version Compatibility

Spartacus 項(xiàng)目由一組庫(kù)組成。 為了更容易知道哪個(gè)版本的庫(kù)與另一個(gè)版本兼容，庫(kù)版本在所有包之間同步。 這意味著當(dāng)我們要發(fā)布 1.5.0 版本時(shí)，我們會(huì)發(fā)布此版本下的所有庫(kù)，即使某些庫(kù)自上一版本以來(lái)沒(méi)有任何更改。 這樣做時(shí)，我們可以使用單個(gè)版本號(hào)來(lái)引用任何給定版本的整個(gè) Spartacus 庫(kù)集。

這也意味著您可以確信，如果您安裝所有具有相同版本的軟件包，那么一切都將正常工作。 不同版本的庫(kù)可以很好地協(xié)同工作，但我們不會(huì)測(cè)試這些配置，也不能保證正確的行為。

version support

對(duì)于版本控制，我們遵循語(yǔ)義版本控制，也稱為 SemVer。 除了穩(wěn)定版本，Spartacus 還生產(chǎn) next 和 rc 版本。

我們對(duì)版本的假設(shè)如下：

• Stable 版本是經(jīng)過(guò)良好測(cè)試的 Spartacus 版本（包括社區(qū)測(cè)試），并且只會(huì)修補(bǔ)錯(cuò)誤。這些版本在 npm 上的最新標(biāo)簽下可用。

• 當(dāng) Spartacus 團(tuán)隊(duì)完成該版本所有新功能的開(kāi)發(fā)后，就會(huì)發(fā)布一個(gè) rc 版本，這意味著功能和公共 API 不會(huì)有任何重大變化。社區(qū)可以安全地開(kāi)始測(cè)試 rc 版本中的功能。 rc 版本可能包含一些錯(cuò)誤，這些錯(cuò)誤將在穩(wěn)定版本發(fā)布之前修復(fù)。當(dāng)沒(méi)有更多錯(cuò)誤并且社區(qū)停止報(bào)告該版本的問(wèn)題時(shí)，我們會(huì)繼續(xù)制作穩(wěn)定版本。

• 當(dāng) Spartacus 團(tuán)隊(duì)完成特定功能時(shí)，將發(fā)布一個(gè) next 版本。這允許社區(qū)立即開(kāi)始測(cè)試該功能。這些 next 版本可能包含很多錯(cuò)誤，功能和公共 API 可能仍會(huì)發(fā)生變化。如果您想盡快測(cè)試新功能，這是適合您的版本。下一個(gè)版本在 npm 上的 next 標(biāo)簽下可用。

注意：強(qiáng)烈建議您不要在生產(chǎn)設(shè)置中使用 next 版本。這是因?yàn)閺膎ext 版本升級(jí)可能比從一個(gè)穩(wěn)定版本升級(jí)到另一個(gè)要困難得多。

Support Policy

始終支持至少一個(gè)穩(wěn)定或 rc 版本。

一旦版本 x.y 發(fā)布，它將被積極維護(hù)，直到版本 x.z 的新穩(wěn)定版或 rc 發(fā)布。 屆時(shí)，版本 x.z 將成為積極維護(hù)的版本，下一個(gè)版本的工作將開(kāi)始。

例如，假設(shè)我們剛剛發(fā)布了 1.5.0-rc.0 版本。 從那時(shí)起，將積極維護(hù) 1.5.x 版本，直到我們發(fā)布 1.6.0-rc.0。 一旦 1.6.0-rc.0 版本發(fā)布，我們就會(huì)將主動(dòng)支持切換到 1.6.x 版本。

注意：對(duì)于重要的安全問(wèn)題或關(guān)鍵的錯(cuò)誤修復(fù)，可能會(huì)有針對(duì)不再積極維護(hù)的版本的附加補(bǔ)丁。

Git Flow

Spartacus 項(xiàng)目中的流程圍繞前面部分中描述的版本支持構(gòu)建。

develop 分支是默認(rèn)分支，用于新版本開(kāi)發(fā)，包括次要和主要版本。 所有功能和錯(cuò)誤修復(fù)都合并到這個(gè)分支。

還有一個(gè) maintenance 分支，它隨著新的穩(wěn)定版或 rc 版本而變化，用于補(bǔ)丁版本。 只有錯(cuò)誤修復(fù)合并到 maintenance 分支。

一旦我們發(fā)布了 1.4.0-rc.0 版本，release/1.4.x 分支將被視為維護(hù)分支。 當(dāng)我們發(fā)布 1.5.0-rc.0 版本時(shí)，則 release/1.5.x 分支成為維護(hù)分支，依此類推。

其他分支約定：

• feature/GH-xxxx 分支用于簡(jiǎn)單的功能和錯(cuò)誤修復(fù)
• epic/epic-name 分支用于大特征（稱為 epics）
• release/1.4.0-rc.0 分支用于特定的發(fā)布（你可以將它們與維護(hù)分支區(qū)分開(kāi)來(lái)，因?yàn)榘暾陌姹咎?hào)）

Flow for Epic Development

• 從 develop 分支創(chuàng)建一個(gè)新的 epic/epic-name分支。

• 從epic/epic-name 為epic 子任務(wù)創(chuàng)建分支，并將它們合并回 epic/epic-name 分支。

• 不時(shí)地使用來(lái)自 develop 分支的更改更新您的 epic/epic-name 分支（它將幫助您管理沖突）。

• 當(dāng) epic 完成時(shí)，創(chuàng)建一個(gè) PR 并將 epic/epic-name 分支合并到 develop 分支。

Flow for Smaller Features

• 從 develop 分支創(chuàng)建一個(gè)新的 feature /GH-xxxx 分支。

• 開(kāi)發(fā)您的功能。

• 完成后，創(chuàng)建一個(gè) PR 并將 feature/GH-xxxx 分支合并到 develop 分支。

錯(cuò)誤修復(fù)流程

以下是處理錯(cuò)誤修復(fù)的步驟：

• 從開(kāi)發(fā)分支創(chuàng)建一個(gè)新的 feature/GH-xxxx 分支。

• 修復(fù)錯(cuò)誤。

• 創(chuàng)建 PR 并將 feature/GH-xxxx 分支合并到 develop 分支。

• 如果此修復(fù)適用于積極支持的版本，請(qǐng)從 maintenance 分支創(chuàng)建一個(gè)新的 feature/GH-xxxx-maintenance 分支。

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

• 創(chuàng)建 PR 并將 feature/GH-xxxx-maintenance 合并到 maintenance 分支中。

Terminology

以下是我們目前使用的可能會(huì)產(chǎn)生誤導(dǎo)的術(shù)語(yǔ)：

“feature freeze” 描述了我們完成了新的次要或主要版本的所有功能的那一刻（這意味著我們希望很快發(fā)布一個(gè) rc，但仍需要修復(fù)一些錯(cuò)誤）。

“code freeze” 描述了我們停止提交代碼的那一刻（盡管這在我們的流程中不是必需的，因?yàn)槲覀兛偸强梢郧袛喟l(fā)布或維護(hù)分支并繼續(xù)提交）。

以下概念可用于替換這些術(shù)語(yǔ)：

我們可以創(chuàng)建一個(gè)新的維護(hù)分支并發(fā)布一個(gè)新的 rc。 第一個(gè) RC 可能有問(wèn)題，因?yàn)?rc 版本可能包含錯(cuò)誤是公認(rèn)的。

我們可以創(chuàng)建一個(gè)新的 release 分支，而不是凍結(jié)代碼。 我們永遠(yuǎn)不需要阻塞主要的開(kāi)發(fā)或維護(hù)分支（我們不需要用這些細(xì)節(jié)來(lái)打擾開(kāi)發(fā)人員，因?yàn)槲覀兊牧鞒讨С衷谶@些分支上并發(fā)工作并發(fā)布另一個(gè)版本）。

term：維護(hù)分支，特性分支

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

示例：你合并了一些東西來(lái)開(kāi)發(fā)，但它需要在 4.0.1 中或者也需要向后移植到另一個(gè)舊的發(fā)布分支，然后你需要?jiǎng)?chuàng)建一個(gè) PR 來(lái)將它合并到 release/4.0.x 。

通常，新功能維護(hù)分支最終是 feature/GH-xxx-maintenance 并將合并到 release/xxx 而不是 develop。

總結(jié)

以上是生活随笔為你收集整理的SAP Spartacus 的 git flow 和发布流程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。