适用于环境的GIT多层配置：[DEV-> QA-> PROD]

Question

我具有以下层次结构，例如多个开发人员在他们的 DEV服务器上推送他们的代码并进行测试，一旦看起来还不错，就应该在 QA服务器上进行质量检查的验证 >，并且质量检查一旦获得批准，则应转到 PROD服务器，该服务器可供客户使用。 e

该代码需要在GIT下维护。

我想知道，关于如何在SDLC下配置这样的CODE流结构的最佳实践是什么。

谢谢。

Answer 1

Git不是版本管理器。您可以强制将其设置为一个，但效果不佳。

相反，这是一个简单的连续发布/交付工作流程的原理。

有一个寿命很长的分支master。

即使在git中，维护长寿命分支也是复杂的，最好避免。您有一个分支可以用来开发和部署：master。

master随时可以发布。

没有准备好发布的东西。这为开发人员提供了一个稳定的开发平台，并为质量检查提供了一个稳定的测试平台，您可以随时自信地部署最新的 complete 功能。

所有开发都发生在功能分支中。

通过在master分支中进行所有开发，可以使master保持高质量。这样可以将每个任务与其他任务隔离开来，并且开发人员可以随意进行试验而不会破坏构建。

换一种说法，您的开发，集成，测试和验收阶段都发生在功能分支中。维护也作为离散功能分支进行。

功能分支定义明确且寿命短。

长期存在分支很痛苦的想法，要素分支应该与一张票证，事件或故事相关联。分支的目的应该定义清楚，完成时应该清楚。完成后，将删除分支，以确保它不会被重用并避免分支混乱。

您的分析和设计阶段必须得出实现任务，这些任务可以分解为多个离散任务，这些任务可以在一个短暂的功能分支中完成。这需要一些练习来学习如何做。

使用git merge --no-ff确保分支保留在提交历史记录的拓扑中。使用合并提交消息记录有关分支的任何重要信息，以备将来考古之用，例如对其正在解决的问题的引用。

A - B ------------- M - N - O [master]
     \             /
      C - D - E - F

这些被称为“特征气泡”。他们清楚地表明，提交C，D，E和F是作为提交完成的，我们应该查看M以获得有关分支的信息。使用git log --graph --decorate来获得这样的视图，或者使用任意数量的Git历史记录可视化器。

功能分支重新建立在主节点上。

为避免要素分支过期，请习惯性地将其与master保持最新。只有在掌握最新功能，解决冲突并通过所有测试后，才能认为功能完整。

为避免过多的簿记合并，请使用git rebase master保持历史记录干净。这是一个过时的功能分支的示例。 F-G“气泡”是一个完整的功能分支。

      F - G
     /     \
A - B ----- H [master]
     \
      C - D - E [feature]

然后重新设置它。

git checkout feature
git rebase master

      F - G
     /     \
A - B ----- H [master]
             \
              C1 - D1 - E1 [feature]

功能分支必须在合并之前通过CI和QA。

这保证了母版随时准备发布。由于功能分支与母版保持最新，因此合并后分支上的QA也是QA的母版。

将master部署到登台和生产。

这就是它的全部目标。没有暂存和生产分支。您可以随时将master部署到暂存。一旦满意，就可以将提交部署到生产中。如果您愿意，也可以git tag staging或git tag production部署的提交。这是Heroku Pipelines之类的东西使用的工作流程。

热补丁如何？

在production标记git branch hot-patch production旁创建临时分支。将热补丁提交到该分支。部署该分支。

一旦紧急情况结束，请尽快将热补丁重做为正常功能分支和正常部署过程。您可以使用git cherry-pick或git rebase在master上获得热补丁更改。部署正确完成的修补程序后，请删除热补丁分支。