git分支规则

Question

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

DEV-> SIT-> PROD

DEV分支是开发分支。开发完成后，会将其推送到SIT分支，并且质量检查人员将SIT源用于测试阶段。为了发布，使用了PROD。

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

1：

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

2：

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

• 将推送从DEV更改为SIT

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

我想知道最佳实践

Answer 1

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

选项1

优点：

1. 由于绕过DEV分支，因此可以更快地测试错误修正。
2. 您可以看到哪个bugfix分支（如果有多个）是最好的方法，然后将其用于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. 由于需要通过DEV给SIT分支进行测试所需的更改/修复，您的速度可能会慢一些。
2. 如果管理不当，DEV可能会淹没分支机构。
3. 如果所有代码都来自DEV，如果您想为不同的客户测试不同的功能，那将需要更多的工作，因为您需要更多的git maintanance来选择要测试的特定版本。

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

Answer 2

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

• Git flow
• Github flow

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

Answer 3

从SIT创建修补程序分支可解决那里的问题。 如果测试通过，则将其合并到SIT，然后从SIT重新构建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功能中发现新错误该怎么办？有新分支吗？

我建议使用Stable mainline branching流。

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

逐步：

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