简体繁体 English

开源项目中 gitflow 的最佳实践

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

原文 2022-09-22 07:56:38 5 1 git/ github/ gitlab/ open-source

I'm starting to work on an open source project at work and we're trying to establish a healthy gitflow branching strategy.我开始在工作中从事一个开源项目，我们正在尝试建立一个健康的 gitflow 分支策略。

Currently, the best option I've found is the " GitLab workflow with release branches ".目前，我发现的最佳选择是“ 带有发布分支的 GitLab 工作流”。 Git Flow Image Git 流图

It seems ok but there are a few questions that come up with this method:看起来没问题，但是这种方法有几个问题：

What happens when I fix a bug in an older version, let's say: v1.2.0 -> v1.2.1 .当我修复旧版本中的错误时会发生什么，比如说： v1.2.0 -> v1.2.1 。 Do I need to cherry-pick the commit to all the newer versions?我是否需要cherry-pick对所有较新版本的提交？
How to deal with release candidates?如何处理候选发布者？ Do I branch from the release branch: v1.2rc_1 or are there better practices for that?我是从发布分支分支： v1.2rc_1还是有更好的做法？

Thanks!谢谢！

1 个解决方案

Does it really makes sense to fix bugs for older version?修复旧版本的错误真的有意义吗？ In most cases - especially for open source projects - bug fixes are introduced into the newest commits.在大多数情况下——尤其是对于开源项目——错误修复被引入到最新的提交中。 It makes sense to fix bugs for particular versions if you had some breaking changes, and users can't simply upgrade to the latest software.如果您有一些重大更改，则修复特定版本的错误是有意义的，并且用户不能简单地升级到最新软件。 So it also depends on how your software is distributed and used.因此，它还取决于您的软件是如何分发和使用的。
Release branch is release candidate itself already.发布分支本身已经是发布候选。 That is the code, which you are going to release.这就是你要发布的代码。 And after that, released code will be merged to master at the end.之后，发布的代码将在最后合并到 master。 So no additional branches from release branch are needed in git flow model.因此在 git 流 model 中不需要来自发布分支的额外分支。