Git Flow - 發佈分支「活躍」時的開發版本是什麼？

我想在一個新項目中使用git-flow。我已閱讀了一些文章，並查看了github項目中提出的一些屏幕錄像。關於版本控制還有一點不清楚。讓我們假設下面的場景，其中Cx是提交，並且提交之上或之下的數字是當時分支的版本。Git Flow - 發佈分支「活躍」時的開發版本是什麼？

   0.1  0.1  0.1   0.2 
- develop ---- C1 ---- C2 ------ C4 ------ Merge ---- 
- release/0.2   \ --- C3 --- C5 ---/ 
          0.2 0.2

所以，有一個從開發分支發佈/ 0.2後一種灰色地帶（在我看來）的。提交C4不完全是0.1或0.2。開發分支在合併release/0.2後發展到0.2，但C4並不是0.2版本的一部分。就個人而言，如果我查看存儲庫並看到v0.2的更新，我會假定在該版本中包含合併提交之前的每個提交。以下是我的期望：

   0.1 0.1 0.2 0.2 0.2 
- develop --- C1 --- C2 --- C3 --- C5 --- C4

我的假設是否錯誤？是不是我們不關心開發的樣子，但我們只關心主人（因爲它是開發+發佈分支的結果）？我猜在下一個版本中，所有這些提交都會根據需要包含在內。

P.S.什麼是你用於夜生活的神器版本？例如0.1快照？正常情況下，不符合0.1-SNAPSHOT < 0.1。另外，根據git流程，你不知道你的下一個發行版本是什麼，直到你分支，所以0.2-SNAPSHOT也是'不允許的'。

來源

2016-11-29 Dimitrios K.

我想說你有點誤會。這是應該的樣子：

   0.1  0.1  0.2   0.2 
- develop ---- C1 ---- C2 ------ C4 ------ Merge ---- 
- release/0.1   \ --- C3 --- C5 ---/ 
          0.1 0.1

C3和C5僅穩定0.1版本。錯誤修正。只要您創建發佈分支，develop分支將包含下一個版本。 git-flow在哪裏說你不知道你的下一個開發版本是什麼？您應該知道下一步計劃的版本，從而相應地調整版本，或者只要增加次要版本，只要執行向後兼容的更改，並在引入向後不兼容的更改時立即衝擊主要版本。沒有人說你不能在沒有發佈中間版本的情況下在開發上做到這一點。

來源

2016-11-29 14:49:33 Vampire

http://nvie.com/posts/a-successful-git-branching-model/#release-branches 「正是在發佈分支的開始，即將發佈的版本得到了一個版本號 - 不是直到時刻，develop分支反映了「下一個版本」的變化，但是不知道這個「下一個版本」最終會變成0.3還是1.0，直到發佈分支開始爲止。開始發佈分支，並按照項目規則的版本號衝突執行。「此外，檢查頁面頂部的圖像:) –

嗯，好點。但是我認爲我會實際上忽略這個細節，並在創建發佈分支後立即增加版本號，並且如果重大更改已完成，則增加主版本，然後在創建下一個發佈分支時，版本號已根據sem-ver或可以重新調整。除此之外，如果您需要維護不同版本的分支，我認爲git-flow無論如何都不適用於許多項目。在第一個大圖中，如果客戶需要版本0.3或0.2.1，你會做什麼？ – Vampire

我完全同意'不適合多項目'部分。但是這是爲了一個小小的庫。儘管如此，仍然沒有認真對待版本控制... –

Git Flow - 發佈分支「活躍」時的開發版本是什麼？

回答

相關問題