開源項目中 gitflow 的最佳實踐

Question

我開始在工作中從事一個開源項目，我們正在嘗試建立一個健康的 gitflow 分支策略。

目前，我發現的最佳選擇是“ 帶有發布分支的 GitLab 工作流”。 Git 流圖

看起來沒問題，但是這種方法有幾個問題：

1. 當我修復舊版本中的錯誤時會發生什么，比如說： v1.2.0 -> v1.2.1 。 我是否需要cherry-pick對所有較新版本的提交？
2. 如何處理候選發布者？ 我是從發布分支分支： v1.2rc_1還是有更好的做法？

謝謝！

Answer 1

1. 修復舊版本的錯誤真的有意義嗎？ 在大多數情況下——尤其是對於開源項目——錯誤修復被引入到最新的提交中。 如果您有一些重大更改，則修復特定版本的錯誤是有意義的，並且用戶不能簡單地升級到最新軟件。 因此，它還取決於您的軟件是如何分發和使用的。
2. 發布分支本身已經是發布候選。 這就是你要發布的代碼。 之后，發布的代碼將在最后合並到 master。 因此在 git 流 model 中不需要來自發布分支的額外分支。