寻找正确的git工作流程

Question

我们是一个小型网络应用程序团队（少于10个）。我们的环境由3个测试环境和12个应用程序的Production组成。我们的测试环境之一是面向客户的功能/修补程序批准（称为Dev），另外两个是隐藏的测试环境，一个用于Dev（称为Pre-Dev），另一个用于生产（称为Pre-Production）。这有助于我们确保对功能/错误进行了合理审查。每个功能在投入生产之前都要经过这3个测试环境，并且某些功能可能需要几个月的时间才能获得客户的批准。

我们需要一种策略，该策略可以使我们实现长时间处于测试状态的功能，同时还可以在迭代过程中以最小的开销实现短期功能和快速错误修复。

我们目前每个环境有一个分支，并使用来自功能/错误修正分支的拉取请求将我们的新代码逐一分发到每个分支。发布时，Pre-Prod分支中的所有内容都被压缩到Prod中并发布。我们正在研究基于中继的工作流程，但我认为长期测试会阻碍我们的发展。有人有主意吗？

Answer 1

据我了解，您需要两件事：

1. 更简洁的git-flow
2. 严格将配置与代码分开

---

1。最简单的git flow

功能/补丁

• master分支中的所有内容均可部署
• 要进行新的工作，请在master之外创建一个描述性命名的分支（即：bugfix_login_error）
• 本地提交到该分支，并定期将您的工作推送到服务器上的同一命名分支
• 当您需要反馈或帮助时，或者您认为分支已准备好进行合并时，请打开拉取请求（或GitLab中的合并请求）。
• 此时rebase，以获取功能/错误修正分支中的master的最新更改。
• 在其他人审核并签署了该功能之后，您可以将其合并到master

修补程序

• 修补程序分支是从master分支创建的。
• 每个修补程序分支都必须合并回master和所有功能/错误修复分支

这个想法是让团队中的每个人都非常简单地理解它，即减少人为错误的唯一方法。有关此方法的更多详细信息，请参见github-flow。

  

经验法则：吻（保持愚蠢简单）

---

2。请勿在每个环境中保留一个分支

将config存储在环境变量中。 Env var易于在部署之间进行更改，而无需更改任何代码。与配置文件不同，它们很少有可能被意外检入代码存储库。

有关此方法的更多信息，请参见The Twelve-factor app。

  

对于一个应用程序是否正确地将所有配置都排除在代码之外的一项试金石测试是，是否可以在不损害任何凭据的情况下随时将代码库设为开源。