Git 工作流建议 - 以满足我的需求



>我已经浏览了许多关于 git 分支和敏捷集成的链接,有了知识,我收集了,我知道我需要什么,但需要帮助如何实现这一目标。

我的要求是:

  1. 一个分支/问题(或)功能
  2. 每月
  3. 发布两个版本(将来每月发布一个版本) - 团队可能同时处理多个发布分支?
    • 我可以使用从 Master 分支出来的许多发布分支,并且将一个功能提交到一个发布分支可以合并到当前发布分支之后创建的其他发布分支中。我可以通过将其合并回来再次将分支释放到 master 中,但现在看看下一点。
  4. 发布
  5. 分支中的功能可能会在发布之前回退。所以我应该有灵活性来决定应该发布什么。而是全部合并到一个分支中?
    • 我想过拥有一个集成分支,以便以后可以将所有计划的修复或功能合并在一起,只有所需的分支可以与 Master 合并。但是我们只在集成分支遵循手动测试(没有具有自动测试的 CI),因此,有了这种方法,我需要创建两个测试设置,一个用于发布,另一个用于集成。

寻找一种方法来解决这个问题,我正在练习不同的组合方法。在这里寻找专家建议。

除了上述所有内容之外,我还在寻找一个灵活的工作流程,可以帮助我随时适应SCRUM/看板,而不会发生重大变化(我们可能会很快转移到看板)。

提前谢谢。

根据您的要求:

  1. 根据 2# 和 3# 要求,您需要有多个分支,因为您需要开发功能才能并行发布。你有主分支master.
  2. 在不同的分支上开发不同的功能,以便您可以单独发布它们,并合并到master中。
  3. 不必在功能分支和master分支之间使用integration分支。将功能分支合并到master分支中,可以使用拉取请求来批准和完成合并。 要按分支发布的功能master,您可以批准拉取请求。否则,您可以将拉取请求挂在那里,因为所有功能分支都是独立的。

若要反映看板上的更改,可以将工作项添加到每个提交中。并且您应该继续使用项目更新工作项状态。

最新更新