哪种分支策略适合我们的团队

时间:2014-06-12 07:08:15

标签: git github version-control workflow git-flow

现在,我们使用SVN作为版本控制,我们从客户那里获得了门票(包括新功能和错误修复),所有开发人员都将更改的代码提交到trunk,并将所有更改部署到QA环境进行测试。但是,并非所有的门票都可以投入生产,有些功能需要客户更多的批准,或者需要在发布之前进行更多测试,因此我们必须从主干和端口选择一些提交回release分支。 release分支中的源代码将是生产。

每个发布时间我们都必须从trunk中选择提交,并且当然我们会有很多冲突(因为如果它们不是发布的优先级,一些提交会丢失),我们必须手动解决冲突。

现在,我们决定将代码库迁移到Git,并且需要引入新的工作流程以使一切顺利,包括发布时间,尽可能少地发布分支和开发分支之间的冲突。

任何人都有这方面的经验,请给我一些建议,应该采用哪种工作流程。以下是一些强制性要求:

  • 所有新功能或错误修复都应该可用于部署到QA环境进行测试,这意味着我们应该有一个包含所有更改的分支
  • 在发布时,并非所有故事都已发布,只有一些提交被选中并移植回来

1 个答案:

答案 0 :(得分:1)

您可能对支持发布分支,修补程序分支和功能分支的 GitFlow 分支模型感兴趣。

post 描述了该提案,并提供了有关如何利用git实现此目的的详细说明。