git 分支的规则

Question

我们有一个大的企业项目，我们有一些发展阶段。我们使用 git。分支看起来像这样：

开发 -> 坐下 -> 生产

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

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

1:

从 SIT 分支创建一个 bugfix 分支，并将其直接从该分支推送到 SIT
重新测试
如果错误已修复，则应创建 DEV 的分支并将其推送到 DEV 并修复此修复。

2:

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

哪个流程是正确的 1 或 2？

我想知道最佳实践

Answer 1

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

选项 1

优点：

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

缺点：

如果 bug 修复不能长期保持，那么 DEV 和 SIT 之间可能会有很多 back-and-forth 发挥，您需要多次 re-apply 对 DEV 的修复。
如果您不小心，DEV 可能会合并到 PROD 中，或者 SIT 会合并到 PROD 中，但其他分支可能会错过这些更改。
工作流程不是一条直线：DEV -> SIT -> PROD，这意味着它可能会混淆哪些变化发生在何处。

选项 2

优点：

工作流程简单易懂。这里没有混淆。
您可以轻松跟踪所有开发级别的变化，而无需担心 SIT 必须测试什么，或者如果 PROD/SIT 或 DEV 是否遥遥领先。
您在 DEV 中编写所有代码，而不是部分代码在 DEV 中，部分代码在 SIT 中。这样你就不会处理很多冲突。

缺点：

为 SIT 分支提供所需的 changes/fixes 测试可能会慢一些，因为他们需要通过 DEV。
如果管理不当，DEV 可能会被分支淹没。
如果你想为不同的客户测试不同的功能，如果你的所有代码都来自 DEV，这将是更多的工作，因为你需要更多的git维护来选择你要测试的特定版本。

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

Answer 2

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

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

Answer 3

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

rebase DEV

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-feature 中发现新错误怎么办？新分支|合并？

我推荐使用Stable mainline branching流。

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

一步一步：

从 prod 创建 feature 分支。
在 feature functional/fixes 中实施。
在 feature 完成基于最新 prod 的变基并强制推送之后。
在 remote/feature 分支上进行测试。
如果您在 remote/feature 中发现错误，请重复步骤 2-4。
Fast-forward 合并 remote/feature 到 prod.

git 分支的规则

The rules of git branching

git

git-flow