我们的做法如下：
我们在合并了最新的开发分支代码后，在功能分支上进行测试，主要原因是我们不想“污染”开发分支代码之前的一个功能被接受。如果一个功能在测试后不被接受，但我们想释放其他功能已经合并在开发，这将是地狱。开发是一个分支，从它的释放，因此应该更好地在一个可发布状态。长版本是我们在许多阶段进行测试。更分析地说：
1.开发人员为每个新功能创建一个功能分支。
1.特性分支（自动）部署在我们的TEST环境中，每个提交都由开发人员测试。
1.当开发人员完成了实现并且特性已经准备好进行测试时，他们在特性分支上重新创建开发分支，并在TEST上部署包含所有最新开发更改的特性分支。
1.测试人员在TEST上进行测试。当他们完成测试时，他们会“接受”故事并将特性分支合并到develop上。由于开发人员之前已经将develop分支基于特性分支，因此我们不希望有太多冲突。然而，如果是这种情况，开发人员可以提供帮助。这是一个棘手的步骤，我认为避免这种情况的最好方法是保持功能尽可能小/具体。不同的功能最终必须合并，当然，团队的规模对这一步的复杂性也有一定的影响。

1. develop分支也（自动）部署在TEST上。我们有一个策略，即使特性分支构建可能失败，develop分支也不应该失败。
   1.一旦我们达到了功能冻结，我们就从develop创建一个发布。这是在STAGING上自动部署的。在生产部署之前，在那里进行广泛的端到端测试。（好吧，也许我有点夸张，他们不是很广泛，但我认为他们应该是）。理想情况下，beta测试人员/同事，即真实的用户应该在那里测试。
   您如何看待这种做法？

在测试之前，我们将开发分支的更改合并到特性分支
不，不要，特别是如果“我们”是QA测试人员。合并将涉及解决潜在的冲突，这最好由开发人员（他们知道他们的代码）完成，而不是由QA测试人员（他们应该尽快进行测试）。
让开发人员在devel之上对他/她的feature分支进行重定基，并推送该feature分支（开发人员已验证该分支在最新的devel分支状态之上进行编译和工作）。
这就允许：

• 在特性分支上进行非常简单的集成（简单的快进合并）。
• 或者，正如下面的Aspasia在评论中推荐的那样，pull request (GitHub)或merge request (GitLab)：维护者在特性PR/MR分支和develop之间进行合并，但前提是GitHub/GitLab没有检测到冲突。

每当测试人员发现bug时，他/她将向开发人员报告并 * 删除 * 当前特性分支。
开发人员可以：

• 修复bug
• 在最近获取的develop分支之上进行重定基（同样，确保他/她的代码与其他已验证的功能集成）
• 按下feature分支。

总体思路：确保合并/集成部分由开发人员完成，将测试留给QA。

最好的方法是continuous integration，一般的想法是尽可能频繁地将特性分支合并到开发者分支中，这样可以减少合并的开销。
尽可能依赖自动化测试，并通过Jenkins的单元测试自动启动构建。让开发人员完成所有工作，将更改合并到主分支中，并为所有代码提供单元测试。
测试人员/QA可以参与代码审查，检查单元测试，并编写自动化集成测试，以便在功能完成时添加到回归套件中。
欲了解更多信息，请查看此link。

我们使用我们所谓的“金”、“银”和“铜”。这可以称为prod、staging和qa。
我称之为大熔炉模型，它对我们很有效，因为我们在业务方面对QA有巨大的需求，因为需求与技术相比很难理解。
当一个bug或功能准备好进行测试时，它会进入“青铜”状态。这会触发一个jenkins构建，将代码推送到一个预构建的环境中。（顺便说一句，不是超级技术人员）只是点击一个链接，不关心源代码控制。这个构建也运行测试等。我们已经在这个构建上来来回回，实际上把代码推到测试\qa环境，如果测试（unit，integration，selenium）失败。如果你在一个单独的系统上测试（我们称之为lead），你可以阻止更改被推送到你的qa环境中。
最初的担心是我们会在这些特性之间有很多冲突。这确实会发生，因为特性X使特性Y看起来像是中断了，但这并不常见，实际上是有帮助的。它有助于在看起来是变化的环境之外进行广泛的测试。很多时候，幸运的是，你会发现你的变化如何影响并行开发。
一旦一个特性通过了QA，我们就把它移到“银”或staging中。运行一个构建，然后再次运行测试。每周我们把这些更改推到我们的“金”或prod树，然后将它们部署到我们的生产系统。
开发者从黄金树开始他们的改变。技术上你可以从staging开始，因为它们很快就会上升。
紧急修复直接进入黄金树。如果一个变化是简单的，很难QA，它可以直接进入银，这将找到它的方式到测试树。
在我们发布后，我们将黄金（刺激）的变化推到青铜（测试），只是为了保持一切同步。
你可能想在推入你的staging文件夹之前重新定基。我们发现时不时地清除测试树可以保持它的干净。有时候测试树中的功能会被放弃，特别是当开发人员离开的时候。
对于大型的多开发者特性，我们创建一个单独的共享仓库，但是当我们都准备好了的时候，我们会把它合并到测试树中。事情往往会从QA中反弹出来，所以保持你的变更集隔离是很重要的，这样你就可以添加，然后合并/压缩到你的staging树中。
“烘烤”也是一个很好的副作用。如果你有一些根本性的变化，你想让它坐一会儿，有一个很好的地方。
另外请记住，我们不维护过去的版本。当前版本始终是唯一的版本。即使如此，您可能也可以拥有一个主烘焙树，您的测试人员或社区可以在其中查看各种贡献者的内容如何交互。

在我们公司，我们不能使用敏捷开发，每一个变化都需要业务部门的批准，这导致了很多问题。
我们使用GIT的方法是这样的：
我们已经实现了“Git流”在我们的公司。我们使用JIRA和只有批准的JIRA票应该去生产。对于测试批准，我们exted它与创建一个单独的测试分支。
处理JIRA门票的步骤是：
1.从开发-分支创建新的分支
1.在分支上执行代码更改
1.从特性中提取测试/QA分支的变更
1.业务批准后，我们将变更从功能分支拉到开发
1.开发在一个版本中频繁进行，最后是主分支
将每个请求拆分到一个单独的功能中，确保只有批准的更改才能投入生产。
完整的过程如下所示：x1c 0d1x

我不会只依赖手动测试。我会用Jenkins自动化测试每个功能分支。我建立了一个VMWare实验室，在所有浏览器的Linux和Windows上运行Jenkins测试。它确实是一个很棒的跨浏览器，跨平台测试解决方案。我测试功能/与Selenium Webdriver集成。我的selenium测试运行在Rspec下。我专门编写了它们，以便在Windows上由jRuby加载。我运行传统的Rspec下的单元测试和Jasmine下的JavaScript测试。我用Phantom JS设置了无头测试。