寻找正确的 git 工作流程

Question

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

我们需要一种策略，让我们能够实现长期保持测试的功能，同时在迭代期间以最小的开销实现短期功能和快速错误修复。

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

Answer 1

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

1. 更干净（更简单）的 git-flow
2. 配置与代码的严格分离

---

1。最简单的 git 流程

功能/错误修正

• master 分支中的任何内容都是可部署的
• 要处理新事物，请从 master 创建一个描述性命名的分支（即：bugfix_login_error）
• 在本地提交到该分支，并定期将您的工作推送到服务器上的同名分支
• 当您需要反馈或帮助，或者您认为分支已准备好合并时，请打开拉取请求（或 GitLab 中的合并请求）。
• 此时rebase 可以在 feature/bugfix 分支中获取 master 的最新更改。
• 在其他人审核并签署该功能后，您可以将其合并到master

修补程序

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

我们的想法是让团队中的每个人都能真正理解它，即减少人为错误的唯一方法。有关此方法的更多详细信息，请参阅github-flow。

经验法则：KISS（保持简单）

---

2。不要在每个环境中保留一个分支

在环境变量中存储config。环境变量很容易在部署之间更改，而无需更改任何代码；与配置文件不同，它们被意外签入代码仓库的可能性很小。

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

一个应用程序是否将所有配置正确地从代码中提取出来的试金石是代码库是否可以在任何时候开源，而不会损害任何凭据。