我已经了解了多种不同的git分支策略，并且我认为主分支经常被用作“生产就绪”分支，并且会有一个额外的uat和dev分支。 我正在考虑使用相同的3个分支来设置我们的git存储库，但是让'master'包含dev代码并添加一个生产和uat分支。这样，开发人员可以简单地合并到默认的git分支（即'master'）。有没有理由不这样做？
GR，
科恩
答案 0 :(得分：6)
没有特别的理由不选择一个工作流程而不是另一个工作流程，使用Git通常由开发团队自行决定他们的最佳实践。
您提到的生产就绪主方法通常具有多个dev分支（有时称为功能分支），然后选择master作为放置所有这些的最终位置，因为通常应该只有一个主分支（通常只有一个生产构建）。
这是多少公司的工作，但肯定不是全部。许多其他人使用“不稳定的主人”方法，其遵循与您提到的方式类似的模式 - 一些具有生产存储库，他们自己的主服务器和分支被认为是不稳定的，并且团队负责人在代码中推送到生产存储库时特定的分支被认为是生产准备好了。
Git的关键方面是每个人都有自己的本地存储库，拥有自己的分支和主服务器。这允许他们随时创建自己的私有分支，无论他们认为合适的任何恶意目的，但它确实使定义分支名称的目的更难以实施。
答案 1 :(得分：6)
使用DVCS（分布式版本控制系统）理解的关键概念是，您没有一个工作流程（在分支之间合并），而是两个：存储库之间的发布（推/拉）。
请参阅＆＃34; What git branching models actually work?＆＃34;
这意味着您将克隆存储库，对于每个克隆，您要问的是：
如果我克隆一个回购＆＃34;默认情况下＃34; （没有特殊参数），我想看哪些内容？
克隆回购邮件中包含的所有可能分支中的内容将是您的master＆＃39;分支。
您可以默认更改＆＃34;分支＆＃34;：请参阅＆＃34; Git: Correct way to change Active Branch in a bare repository?＆＃34;。
因此，如果您有一个专门用于开发的仓库，主分支将代表最新的代码＆＃34;该工作＆＃34;，与其他分支进行各种＆＃34;实验＆＃34;正在进行中 这基本上就是Git回购本身所遵循的内容：参见＆＃34; Git/Git Workflow＆＃34;。
但是任何其他克隆都可以专用于其他开发生命周期步骤（uat - 用户验收测试，坐 - 系统集成测试， - pre-prod或prod）。
在这种情况下，他们的master＆＃39;分支将具有不同的含义，适应该回购所扮演的角色。
答案 2 :(得分：2)
我认为一个好的起点是实际阅读Git's recomended workflow document.他们谈论使用master作为稳定和功能分支。
摘录：
毕业 ~~~~~~~~~~
由于给定的功能从实验到稳定，它也是 ＆＃34;毕业生＆＃34;在软件的相应分支之间。
git.git使用以下“集成分支”＆＃39;：
＆＃39; MAINT＆＃39;跟踪应该进入下一次维护的提交 发布＆＃34;，即更新上次发布的稳定版本;
＆＃39;主＆＃39;跟踪应该进入下一版本的提交;
＆＃39;下一个＆＃39;旨在作为测试主题的测试分支 主人的稳定性。
第四个官方分支的使用方式略有不同：
- ＆＃39; PU＆＃39; （建议的更新）是一个集成分支 尚未准备好纳入（参见＆＃34; Integration Branches＆＃34; 下文）。
四个分支中的每一个通常都是该分支的直接后代 在它之上。
从概念上讲，该功能进入一个不稳定的分支（通常是＆＃39; next＆＃39; 或者＆＃39; pu＆＃39;）和＆＃34;毕业生＆＃34;到＃＆＃39;掌握＆＃39;一旦它是下一个版本 认为足够稳定。
答案 3 :(得分：1)
这一切都取决于开发人员的舒适度。你可以继续你解释的方法。还可以有多个分支用于基于sprint或任何其他方法进行提交。 每次要将代码部署到生产环境中时，请合并已推送提交的特定分支以及方法。