持續交付，版本控制和功能分支混亂

我目前正在使用Feature Branch Workflow實施CD。我不清楚什麼時候增加版本號。持續交付，版本控制和功能分支混亂

創建新功能時應該增加嗎？

所以我們假設我們有版本1.1，並且我要實現一個新功能FB-123。

創建FB時，我應該增加版本嗎？

 *---*--- increment build number, now on 1.2.456 
    /increment version to 1.2 
    ---* 1.1

，並使用詹金斯建立後，犯多少？

這一切都真的dep結束於構建號碼的用途。內部是否需要幫助解決這個問題？這是否讓其他技術人員看到，因此他們可以推斷出構建編號的語義發生了什麼變化？這值得一讀 - http://semver.org/給你一些思考的食物 –

@EvolveSoftwareLtd是的，它是爲了解決它。我真的不介意它是否是語義的。 – helpermethod

你使用git嗎？功能分支完成後會發生什麼？你是否將它合併回主或釋放分支？ –

我會考慮使用以下版本的模式：

每一個主要/次要版本將被標上git標籤
分支架構 - <major>.<minor>.<number of commits from latest minor>-<feature branch-name>-<sha1>
主模式 - <major>.<minor>（它認爲每接受的拉取請求是次要版本）

您可以計算從最近的次要的提交次數

git rev-list HEAD ^<latest minor tag> --ancestry-path <latest minor tag> --count

該模式將允許您從版本名稱派生：

2016-09-01 09:37:57

回答