问题标签 [github-flow]

我们遵循 GitHub 流程策略（创建功能/错误修复分支，并在完成后通过拉取请求将它们合并回来）。我们还会在发布软件的每个新版本时标记版本。

我们在旧版本（比如 tag v1.0.0）中发现了一个错误，并将其修复在该标记的“错误修复分支”中，如下所示：

我想将 bugfix-branch 合并到 master 的当前负责人中（其中包含我们还不想发布的东西），但也想v1.0.1基于旧的标记版本创建一个标签（逻辑上就在 之后v1.0.0，其中 * 显示下面）我们可以发货。

希望更清楚，错误修复分支包含 3 个提交。我可以吗：

1. 将错误修复分支合并到 master（最好作为 squash 提交）
2. 将错误修复分支的头标记为v1.0.1
3. 删除错误修复分支（但保持标签v1.0.1完好）？

给：

在工作中，我们现在正在使用 GitHub，并使用该 GitHub 流程。我对 GitHub Flow 的理解是有 master 分支和 feature 分支。与 git flow 不同，没有开发分支。

这在我们已经完成的项目上非常有效，并且简化了事情。

但是，对于我们的产品，我们有一个开发和生产环境。对于生产环境，我们使用master分支，而对于开发环境，我们不知道该怎么做？

我能想到的唯一想法是：

1. 当分支与 master 合并时，使用 GitHub 操作重新部署 master。
2. 当推送另一个分支时，设置一个 GitHub 操作，以便将任何其他分支（除了 master）部署到此环境。

目前，对于需要开发环境的项目，我们本质上是在使用 git flow（功能 -> 开发 -> 主控）。

您认为我的想法是否明智，如果不是，您会推荐什么？

编辑：

澄清一下，我问的是使用GitHub Flow而不是git flow实现开发的最佳方式。

使用 GitLab

收到以下错误消息。

要遵循的解决方案。

对于使用基于 Trunk 开发的开发人员，您是如何处理代码库中不断增长的功能标志集合的？

我担心的是，如果您在每个版本和每个新功能中都大量使用功能标志，那么功能标志代码的数量会不会开始降低代码的可读性并且可能更难以维护？为了这个问题，假设功能标志由外部 FFaaS 处理。

根据我自己的推理，我可以看到几个选项：

• 永远不要删除功能标志。保留它们以备不时之需（例如，用于取消您在以后逐步淘汰的功能）。
• 定期删除保留 X 时间的旧功能标志。这解决了代码可读性问题，但这打破了基于主干的部署范例，因为您失去了打开/关闭标志的后备措施，因为标志本身正在被删除。您也可能会在上述情况下丢失，您必须手动跟踪功能以逐步淘汰，或者可能重新引入功能标志以促进一些类似的过渡。

人们是如何使用这个开发系统处理物流的？

在我的一个项目中，我们正在使用 GitHub 流。分支模型如下：

1. 在 Jira 上创建票证 (OSCS-103)
2. 从 中创建一个分支master，称为OSCS-103。
3. PR 一经创建就在此分支上创建，具有可以测试它的自定义环境，UI 位于oscs-103.x.com.
4. 关闭 PR 后，将删除环境（使用 Terraform）。
5. 中的所有master内容都已考虑int并已准备好发布，可以通过int.x.com.
6. 创建发布后，其中的所有内容master都会被推送到 prod 环境，x.com

目前，为每个分支创建不同环境的过程是“手动”的，我们运行以下命令：

这在 Terraform 中启动了一个新环境，我们使用它source_branch来创建管道。

一旦我们完成了这个环境，我们执行：

但是，我想自动化这个过程，这样每当创建 PR 时，就会自动创建一个 env（最好使用 AWS CodePipeline 或 AWS CodeBuild），并且当 PR 关闭/合并时，env 会被销毁。

有没有人有他们这样做的例子？

编辑：

澄清一下，terraform上面的命令正在创建一个管道，这个管道“监听”上的变化source_branch并运行一个脚本来检查基础设施的变化（使用 terraform 并在必要时进行更改），重建和部署 UI，重建和部署API，以及运行flyway以迁移数据库更改。

我有一个关于 GitHub 流程的问题，特别是关于如何管理同时开发的多个功能的问题。

假设我们有一个简单的 CSS 文件。

假设开发人员 A 负责将背景颜色更改为红色，而开发人员 B 负责将字体颜色更改为黑色。

开发人员 A 创建其功能分支“red-background”，更新 CSS 文件并在其分支中提交更改。“red-background”分支中的 CSS 文件现在是：

开发人员 B 创建其功能分支“black-font”，更新 CSS 文件并在其分支中提交更改。“black-font”分支中的 CSS 文件现在是：

现在，如果审阅者将“red-background”合并到 main，然后将“black-font”合并到 main，则会出现 git-merge 冲突：

在这些情况下如何避免冲突？

我有点困惑，原始文档说如果我们有发布分支，我们应该使用cherry-pick。（我在任何地方都找不到从发布分支创建 PR 回到主干的说法） https://trunkbaseddevelopment.com/

developer creates a pull request, to the trunk branchlaunch 在他们的帖子中暗暗地说明了这一点：https ://launchdarkly.com/blog/introduction-to-trunk-based-development/

如果我们这样做，对我来说看起来更像是GitHub Flow分支策略，而不是Trunk Based Development. 有什么意义，还有什么是核心差异？

• 而且我对这个文档感到困惑（太跳跃并通过这种分支策略打破了先前规定的规则）： https ://trunkbaseddevelopment.com/short-lived-feature-branches/

任何输入/清晰度将不胜感激。

• 一个完整的 gitflow 生命周期是什么样的？
• 哪个分支被推送到生产环境：release或main？
  
  

我对这个话题进行了深入的研究。但这些是我找不到答案的问题。
任何建议都非常感激。提前致谢。