我需要一些帮助来规划工作流程如何用于最近转换为Git的特定站点开发环境(来自SVN).
我在客户端服务器上有4个开发人员,实时和登台站点,以及一个托管"hub"(裸仓库)以及2个开发人员回购站的开发服务器.我们有几个里程碑的变化要处理,具有未知的完成顺序并由多个开发人员处理.此外,实时网站需要动态完成许多快速修复.
我的主要问题是:
我的大脑开始循环,试图找出最佳的工作流程.作为这篇文章的参考,让我们说我有两个里程碑的变化:移动和重新设计.这是我到目前为止所提出的:
每个开发人员仓库,集线器仓库和阶段仓库都有这些分支:移动,重新设计,主控.现场回购有一个分支:主人
快速修复:开发人员对其主分支进行更改,然后推送到集线器.然后在现场,从中心拉出更改(如果他们需要事先在那里测试,则先进行阶段).
最终阶段和发布"重新设计"MILESTONE:开发人员将重新设计分支推送到集线器并在阶段进行更改.客户端测试和批准.在中心,开发人员将重新设计合并到主人(并且我认为在这里创建一个标签),然后在现场拉主人.或者开发人员在他的副本中合并分支,然后将他的主人推送到集线器会更好.另外,如果创建了一个标签,最好是在现场拉标签(如果可能)而不是拉动主分支？标签应该只驻留在集线器仓库上吗？
除了“合并”部分之外，工作流程似乎很合理。
我总是在任何合并之前先进行变基：开发人员在主分支之上对其工作进行变基，以便在本地解决任何冲突（就像我在“变基与合并”中描述的第一个场景）。
这将使任何后续合并（在初始变基之后）成为快进合并。
（Jefromi在评论中提到，变基并不总是可能的。
确实，每当某些工作已经被推/拉到其他地方时，变基相同的工作是危险的。）
至于实时拉取标签或主控，我宁愿只部署标签，而不是HEAD分支的标签。这意味着我会在实时推送一个裸存储库，它会设置一个钩子，仅当所述标签位于分支（可以轻松检查）post-receive时才使用标签更新非裸存储库（实际实时站点）HEADmastergit describe
| 归档时间： |
|
| 查看次数： |
1098 次 |
| 最近记录： |