有哪些最常见的Git分支方案/提交生命周期?

mac*_*ost 9 git git-branch

首先,对不起,如果这是重复,但我尝试搜索,所有我能找到的是如何在Git和诸如此类的分支.那不是我想要的那么多; 我试图找出不同的人如何设置他们的Git分支以匹配他们的工作流程.

让我举个例子说明我们公司是如何做到的:

  1. 开发人员在本地提交他们自己的分支
  2. 开发人员将提交推送到他们的远程,其中连续构建系统检查它,另一个开发人员检查它
  3. 如果审核/构建通过,则提交将合并到QA分支中(如果失败,则会在审核/构建通过之前进行更多提交)
  4. 如果提交失败QA,则进行还原提交以将其取出
  5. 在准备好足够的QA提交后,我们的主分支获得提交(QA分支基于它,因此不需要合并)
  6. 定期分支取自主分支,并用于释放"进入野外".如果在此处发现问题,则将再次使用还原提交来删除代码
  7. 发布后,开发人员将他们的分支机构重新分支到主分支(获得他们以前的提交和其他开发人员的提交)

现在,这个系统存在一些问题; 我会在评论中注意到一些,但我并不是真的在寻找"请为我修复我们的系统",我只是想看看我们可以使用的其他分支选项,以便我可以权衡各种可能性.

所以,如果你曾经在多家使用过Git的公司工作过(或者更好,如果你是一位看过大量Git设置的顾问),请你分享一下:不同的公司如何设置Git分支(以及移动提交)他们之间)促进发展的各个阶段......尽可能地尽量减少烦恼?我敢肯定必须有一些共同的模式......但我不知道它们是什么.

PS如果您只看过一个Git设置,但您认为它很有意思,请务必发布.但是,我想将答案提供给那些提供最佳可能选项细分的人,我希望这会来自已经看过几个Git设置的人.

Chr*_*ken 6

我现在一直在管理几个使用Git的团队,我们已经制定了一个非常适合我们的策略.

  • 师父总是完全正在制作什么.代码发布后,当前分支会快速转发给master,并添加一个标记,以便及时标记版本,如果需要,我们可以获取代码.
  • 开发人员可以自由地按照他们的分支方式工作,但是对于功能分支,我们通常为每个功能分配一个分支,并且多个开发人员与该分支进行合并以共享该功能的工作.
  • 当它的发布候选者的时间,RC_XXX分支被创建,并且足够远的特征分支都被合并到它中.然后对此进行测试,并修复错误.
  • 完成所有操作后,RC_XXX分支将被释放到生产中,在它"坚持"几天之后,我们将其推广到掌握,然后新的功能分支将基于它.

这非常有效,因为只需分离master就可以轻松创建和部署针对生产的热修复,并且开发人员可以根据需要分支功能分支以引入依赖关系.