git分支规则

Question

我们有一个大型企业项目，我们有一些发展阶段。我们使用 git。分支如下所示：

DEV -> SIT -> PROD

DEV 分支是开发分支。开发完成后，它被推送到 SIT 分支，QA 使用 SIT 源进行测试阶段。对于发布，使用 PROD。

那么问题来了：如果 DEV 已经完成并且 SIT 测试已经开始并且发现了一个 bug，那么正确的流程是什么？

1：

• 从 SIT 分支创建错误修复分支并将其直接从分支推送到 SIT
• 重新测试
• 如果错误得到修复，则应创建来自 DEV 的分支并将其推送到 DEV 并修复此修复。

2：

• 从 DEV 创建一个分支并将错误修复推送到 DEV。

• 将更改从 DEV 推送到 SIT

什么流程是正确的 1 或 2？

我想知道最佳实践

Answer 1

这两者都是您可以使用的有效策略。

选项 1

优点：

1. 您可以更快地测试您的错误修复，因为您绕过了 DEV 分支。
2. 您可以查看哪个错误修复分支（如果有多个）是最好的方法，并使用该方法将其放入 DEV，然后放入 PROD。
3. SIT 与 DEV 分离，因此您可以继续在 DEV 上工作，而不必担心 SIT 必须测试什么。

缺点：

1. 如果错误修复不能长期有效并且您需要多次将修复重新应用到 DEV，则 DEV 和 SIT 之间可能会有很多来回的操作。
2. 如果您不小心，那么 DEV 可能会合并到 PROD 中，或者 SIT 到 PROD 中，但随后其他分支可能会错过这些更改。
3. 工作流程不是一条直线：DEV -> SIT -> PROD，这意味着它可能会混淆哪些更改去哪里。

选项 2

优点：

1. 工作流程简单易懂。这里没有混淆。
2. 您可以轻松跟踪所有开发级别的更改，而无需担心 SIT 必须测试什么，或者在 PROD/SIT 或相反情况下 DEV 是否领先太多。
3. 您在 DEV 中编写所有代码，而不是在 DEV 中编写部分代码，在 SIT 中编写部分代码。这样您就不会处理很多冲突。

缺点：

1. 为 SIT 分支提供测试所需的更改/修复可能会慢一些，因为它们需要通过 DEV。
2. 如果管理不当，DEV 可能会因分支而不堪重负。
3. 如果您想为不同的客户测试不同的功能，如果您的所有代码都来自 DEV，那么工作量会更大，因为您需要更多的 git 维护来选择要测试的特定版本。

个人我喜欢第二个选项，因为它更精简且易于在 DEV 中维护。您还可以查看这些workflows 以获得其他想法。

Answer 2

这个问题没有“正确”的答案，但作为开发人员，您不应该重新发明轮子。 已经有广泛接受的独立于项目的分支策略：

• Git flow
• Github flow

我建议您通读它们并与您的团队一起决定。并且只应用这些流程。还有一些工具可以强制执行每种策略。

Answer 3

从 SIT 创建一个修补程序分支修复那里的问题。 如果测试通过，将其合并到 SIT，然后将 DEV 从 SIT 变基

SIT -> create branch fix/issue

QA PASS -> merge fix/issue into SIT -> rebase dev from SIT

Answer 4

Git 流程很大程度上取决于您的开发环境和堆栈。 Github、Bitbucket 和 GitLab 都有自己的建议和最佳实践。

我建议阅读所有这些： Github flow, Bitbucket recommendations, GitLab flows.

对我来说，您的两个错误修复选项都不是最佳的，并且使流程更加复杂。为 butfix 创建额外的无用分支，而不是对 SIT 或 DEV 进行新的合并。所有这些操作都没有任何意义。如果您在 DEV 功能中发现新错误怎么办？新分支|合并？

我建议使用Stable mainline branching 流。

feature -> pull --rebase PROD & push -f -> remote/feature -> QA testing -> PROD
   |                                                            |
  FIX    <---                    <---                     <--- bug

一步一步：

1. 从prod 创建feature 分支。
2. 在feature 功能/修复中实现。
3. 在feature 完成后将其重新设置为最新的prod 并强制推送。
4. 在remote/feature 分支上进行测试。
5. 如果您在 remote/feature 中发现错误，请重复步骤 2-4。
6. 快进合并 remote/feature 到 prod。