我已经阅读了有关多种不同的git分支策略的内容,并且我认为主分支经常被用作"生产就绪"分支,并且会有一个额外的uat和dev分支.我正在考虑使用相同的3个分支来设置我们的git存储库,但是让'master'包含dev代码并添加一个生产和uat分支.这样,开发人员可以简单地合并到默认的git分支(即'master').有没有理由不那样做？
GR,
科恩
没有特别的理由不选择一个工作流程而不是另一个工作流程,使用Git通常由开发团队自行决定他们的最佳实践.
您提到的生产就绪主方法通常具有多个dev分支(有时称为特征分支),然后选择master作为放置所有这些的最终位置,因为通常应该只有一个主分支(通常只有一个生成构建) ).
这是多少公司的工作,但肯定不是全部.许多其他人使用"不稳定的主人"方法,其遵循与您提到的方式类似的模式 - 一些具有生产存储库,他们自己的主服务器和分支被认为是不稳定的,并且团队负责人在代码中推送到生产存储库时特定分支被认为是生产就绪.
Git的关键方面是每个人都有自己的本地存储库,拥有自己的分支和主服务器.这允许他们随时创建自己的私有分支,无论他们认为合适的恶意目的,但它确实使定义分支名称的目的更难以实施.
使用DVCS(分布式版本控制系统)理解的关键概念是,您没有一个工作流(分支之间的合并),而是两个:存储库之间的发布(推/拉).
请参阅" git分支模型实际上有哪些功能？ "
这意味着您将克隆存储库,对于每个克隆,您要问的是:
如果我"默认"克隆一个回购(没有特殊参数),我想看到什么内容？
克隆回购包含的所有可能分支中的内容将是您的master"分支".
您可以更改"默认分支":请参阅" Git:在裸存储库中更改Active Branch的正确方法吗？ ".
因此,如果您有一个专门用于开发的仓库,那么主分支将代表最新的代码"工作",其他分支正在进行各种"实验".
这基本上就是Git repo本身所遵循的内容:请参阅" Git/Git工作流程 ".
但是任何其他克隆都可以专用于其他开发生命周期步骤(uat - 用户验收测试,sit - 系统集成测试, - pre-prod或prod).
在这种情况下,他们的' master'分支将具有不同的含义,适应该回购所扮演的角色.