小型团队的Git工作流程


11

我正在制作一个git工作流程,以在一个小型团队中实施。工作流程中的核心思想:

  • 有一个共享的项目主管,所有团队成员都可以写
  • 所有开发仅在功能分支上完成
  • 功能分支由分支作者以外的团队成员审阅的代码
  • 功能分支最终合并到共享母版中,并且循环再次开始

本文详细解释了此循环中的步骤:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

这有意义还是我错过了什么?

Answers:


16

我喜欢git flow分支模型。master分支在大多数情况下都处于单独状态,它仅包含发行版。开发分支应始终保持稳定,并且功能分支可以断开。

您还可以通过将开发合并到功能分支并将功能分支合并到开发来将其与持续集成结合起来。当然,只有在确信一切正常且不会中断的情况下,才应将某些内容合并到开发中。


据我了解,git flow和持续集成是替代的工作方式,实际上并不能结合在一起。在git flow中,仅当功能完成时,代码才会合并到development中。在持续集成中,所有代码每天至少合并一次到一个共享分支中,即使它没有立即提供任何新功能。
bdsl '17

7

我认为您缺少主题“持续集成”。它应该是每个开发设置的一部分。

使用功能分支时,您会遇到问题,即不能连续集成,而只能在功能完成后才能集成。

如果分支的功能是短暂的,这可能是可以接受的,但是绝对应该考虑这一点。

另一种方法是为每个功能分支设置CI构建。这肯定有帮助,但不是集成。一旦发现第一个没有出现在功能部件A或功能部件B中的错误,而是在集成功能部件A&B的那一刻,这一点就变得显而易见。

第三种选择是合并到CI构建的某些集成分支中。这是真正的集成,并且如果工作有些分离,则实际上可以与git一起很好地工作,但是在构建期间会导致合并冲突,从而导致构建失败。


master分支可以与CI挂钩,如果功能分支合并未通过自动非回归测试,则拒绝它们。感谢您的提示,我将在末尾添加“提示”部分,并在此进行提及。
janos

1
当然,但是正如所说的,这不是连续集成,而是功能集成的尽头,这可能是很好的方法,但并不相同
Jens Schauder

1
我认为功能分支非常有用,因为它们不需要稳定。这意味着您可以频繁提交,而不必进行大量提交。
Arjan 2012年

按计划运行的自动化构建过程(CI系统)是必不可少的。它需要经常运行,以便可以快速找到并解决编译问题。开发团队应优先考虑构建失败。当这些问题首次出现时,要解决这些问题要容易得多。
内森·皮林

1
对于使用CI的项目(目前有几个无法使用它的旧项目),我们承诺一切都掌握真正的CI,对于我们的旧项目,我们使用git流分支模型。如果您问我,功能分支是CI阻止程序,它们使连续(不仅是完成时)集成变得更加困难。我们一直在研究功能,最后的任务是基本上将其打开,但是代码始终在项目中。
艾略特·布莱克本2014年

1

您可以从gitflowTwgit获得灵感。

gitflow将其方法总结为:

Git扩展可为Vincent Driessen的分支模型提供高级存储库操作。

Twgit描述自己如下:

Twgit是一个免费的开源辅助工具,用于管理Git存储库中的功能,修补程序和发行版。它提供了简单的高级命令来采用我们的文档中描述的分支模型。支持的操作系统:Debian / Ubuntu Linux,Mac OSX。

两种工具都可以从github获得

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.