2012-07-22 83 views
0

我们目前为不同的项目提供了多个Git回购协议。git分支模型

目前我们有以下工作流程: 大师 - 一切都在这里提交 部署 - 直播服务器

上使用的生产代码,我们有哈德森CI对每一个新的检查主承诺。每分钟轮询一次更改。 我们还有一个登台服务器,用于签署在我们的主分公司部署之前测试物理功能的工作请求

我们现在看到的主要问题是我们在工单/工作请求的基础上工作,我们可能并不总是希望在发布基础上部署所有变更,但是如果和当票证从高级员工签署时。

我已经看了Git的流量和github上流动的喜欢。两者都有它们的优点,但是我无法找到一个包含登台服务器和ci的策略。

阅读任何帮助或建议将不胜感激!

更新1

我们的工作流程应遵循以下几点:

Production: -------------I-----------O---- 
         /  /
      B---E---F---G J---K---L 
Master: A--/--C---D---H--\--/---M---N-\--- 
      \-1-/-2-/-3-/  \-1-/-2-/ 

Ci和师父所有的运行,所有的工作都进行的一个分支,合并,分期分段区域。 将特征/故障单分支中的退出工作合并到生产中,仅在特定分支中进行更改。

纠正我,如果这是错误的,或者如果任何人有这个

回答

1

让您拥有一个主分支更好的解决方案和任何承诺有去督促和一个临时分支,任何犯有去临时服务器我把它..

所以这对我来说很有意义。每票应该是它自己的分支关老爷。从那里,一个开发者可以合并成阶段来测试那里..一旦它通过测试并签署,该分支是好的去。从那里你可以决定将哪些分支合并到你的“发布”分支中,并将该分支合并到主控中进行部署。

你可以发布分支甚至合并举办测试版本有一个更多的时间,以确保每个分支玩弄他人不错。

或..如果您使用github ..只需让每个开发人员根据门票分支一个新分支..然后发送一个PR到主人