簡體   English   中英

開源項目中 gitflow 的最佳實踐

[英]Best practices for gitflow in an open source project

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

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

看起來沒問題,但是這種方法有幾個問題:

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

謝謝!

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

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM