的Git分支策略，如何把各种环境问题没有

寻找咨询如何设置GIT中支持多个开发人员的工作特点，以及我们如何推动我们的各种环境，如开发，质量保证和UAT。的Git分支策略，如何把各种环境问题没有

我在想是这样的：

dev_branch 
- new features get a feature branch i.e. dev_branch_feature_x 
- once feature is completed, it gets merged into the dev_branch 
- dev_branch then merges into main_branch 

main_branch 
- code must be merged into main to push to UAT 
- once uat is signed off, it gets pushed to production

的一个问题是，是否有feature_branch意味着我们需要为每个单独的feature_branch开发和QA环境？

如果2个开发者对要素的工作，他们不能直接把他们的到QA环境的变化，因为他们会在彼此写。我不确定他们是否可以将两个更改合并到同一个分支中，然后推送它们可能存在的冲突。

上述分支模型是否可行或者您是否建议其他内容？

来源

2012-06-21 loyalflow

第二个人推代码不“覆盖”第一人的变化，他的推失败告诉他，他必须先拉和执行合并之前，他可以推。 – meagar

@meagar但是如果功能分支正在发生变化，你不能指望它们拉动，所以我猜这有赖于你需要一个单独的环境来推动到没有？ – loyalflow

您的开发人员不应该将代码压得太厉害，以至于他们不希望其他人使用它。在Git中推动*需要*其他人拉动。如果你不能接受这个基本事实，你就不能使用Git。 – meagar

一个非常受欢迎的使用Git使用工作在http://nvie.com/posts/a-successful-git-branching-model/

主要是描述你最成功的做法是，有一个开发环境，它是一个长期运行的分支，它可能是，如果你的行李箱希望或可以成为一个单独的分支，在这个文档中一个名为'develop'。

问题分支和开发分支将会从这个被分支，开发和测试，然后合并回时，笔者认为它们是稳定的。然后，如果您在开发时需要进行任何测试以使其符合进入下一个测试级别的通行证，则您将其标记并构建并将其部署到测试环境中。

当你越来越接近释放，你会从发布分支，然后只触及，以提高其对发行稳定运行发展支行。这使得它成为一个死胡同的分支，但是稍后应用热修复的好地方。

如果你是在想要树干被部署到生产的最新版本，那么无论什么时候事情已经通过了所有的测试和部署到生产那些地方之一，你把它合并到干线。这是选项;在我看来，这是不必要的开销和复杂性，但它是你经常遇到的管理需求。

来源

2012-06-25 22:46:04

的Git分支策略，如何把各种环境问题没有

回答

相关问题