我正在制作一个git工作流程,以在一个小型团队中实施。工作流程中的核心思想:
- 有一个共享的项目主管,所有团队成员都可以写
- 所有开发仅在功能分支上完成
- 功能分支由分支作者以外的团队成员审阅的代码
- 功能分支最终合并到共享母版中,并且循环再次开始
本文详细解释了此循环中的步骤:
https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md
这有意义还是我错过了什么?
我正在制作一个git工作流程,以在一个小型团队中实施。工作流程中的核心思想:
本文详细解释了此循环中的步骤:
https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md
这有意义还是我错过了什么?
Answers:
我喜欢git flow分支模型。master分支在大多数情况下都处于单独状态,它仅包含发行版。开发分支应始终保持稳定,并且功能分支可以断开。
您还可以通过将开发合并到功能分支并将功能分支合并到开发来将其与持续集成结合起来。当然,只有在确信一切正常且不会中断的情况下,才应将某些内容合并到开发中。
我认为您缺少主题“持续集成”。它应该是每个开发设置的一部分。
使用功能分支时,您会遇到问题,即不能连续集成,而只能在功能完成后才能集成。
如果分支的功能是短暂的,这可能是可以接受的,但是绝对应该考虑这一点。
另一种方法是为每个功能分支设置CI构建。这肯定有帮助,但不是集成。一旦发现第一个没有出现在功能部件A或功能部件B中的错误,而是在集成功能部件A&B的那一刻,这一点就变得显而易见。
第三种选择是合并到CI构建的某些集成分支中。这是真正的集成,并且如果工作有些分离,则实际上可以与git一起很好地工作,但是在构建期间会导致合并冲突,从而导致构建失败。