将develop分支设置为pull请求的默认值

ton*_*ung 21 git github git-flow pull-request hubflow

我希望默认情况下将pull请求合并到功能分支中.

我主张使用git流,所以当为一个功能提交一个pull请求时,pull请求需要合并到develop中,而不是master.

一些管理人员评论说,作为人,团队领导可能会忽略这一事实并将错误的拉取请求合并到主人,导致后期发布问题.

我们希望降低合并地狱的风险,因此这将大大有助于实现这一目标.

编辑:我正在使用名为hubflow的gitflow分支(http://datasift.github.com/gitflow/).默认情况下,创建 git hf feature start [tik-123] 要素分支时,会根据规范创建要素分支,但也会将其推送到原点.我们想要这个用于合作.功能完成后,开发人员将转到github中的功能分支并发出拉取请求.然后,如果要在sprint中发布该功能,团队负责人将检查pull请求并将该功能合并到dev中.

Ian*_*sco 19

或者,创建develop每个人在访问项目时看到的默认分支.缺点是任何克隆它的人默认会得到一个不稳定的分支,但是默认情况下所有的pull请求都会转到develop分支.

  • 我假设downvote来自一个习惯于公共回购工作的人.我是私人仓库的私人商店,所以无论如何我们默认从dev分支.我会尝试你的建议,如果它有效,那么我会把它标记为答案.您是否有机会知道如何更改默认分支? (5认同)
  • 如果人们习惯于将git clone,cd放入新克隆中,然后再进行git flow init并在每个git-flow提示符下按Enter,那么将`develop`设为默认的GitHub分支也容易出错。获取git-flow的默认设置。但是,当检出的分支为`develop`时,git-flow会建议将其作为“生产版本的分支名称”,这不是默认设置所需要的。 (2认同)

Jos*_*ner 9

而不是使用masterdevelop分支,使用stablemaster.

然后在标记新版本之前合并它们通常是好的,因此没有或只有很少的转移.我使用这种模式,通常stable遵循master小延迟,合并大多是快进.

要保持master分支可部署,请在功能准备就绪时合并功能分支.但由于你有stable分支,新功能不需要经过充分测试.


xer*_*ero 5

github有自己建议的工作流程github flow,按照惯例,所有拉取请求默认为,master但是您现在可以将其编辑为所需的任何分支。

  • 好糟糕。它是他们的系统,所以我想他们可以按照他们想要的方式工作。鉴于git flow的流行程度,我认为他们会考虑支持它,即使他们不想自己使用它。 (3认同)