git (git flow) 的通用工作流程使用功能分支，其中为每个新功能创建一个单独的分支。开发人员在这些独立的分支上实现新功能，然后将他们的更改合并回 分支或 分支。 main master 该工作流的好处很明显：可以在 QA 环境中方便地部署和测试一个单独的分支，如果检测到严重错误，它根本不会合并到 分支中。可以在同一分支中修复问题并改进代码。 main 同时，主分支仍然可以持续部署并免受这些问题的影响。 不幸的是，这种策略有一个明显的缺点——合并冲突。对于在某些时候不可避免的长寿命分支，这些冲突可能很难解决，因此更容易完全摆脱分支并从头开始。 同样，当它有很多冲突时，合并结果可能是不可预测的。 但是，这不是唯一可能的策略，本文将介绍一种替代方法来管理新产品功能，而没有上面列出的缺点。 为什么会出现合并冲突？ 根据 Git 的设计，当分支在同一个文件行中有不同的内容时，在合并过程中会发生合并冲突。 为了说明这一点，让我们考虑一个场景，其中两个团队正在实施对同一服务的更新。团队 A 正在整合信用卡支持，而团队 B 正在改进用户配置文件页面。这些功能似乎彼此无关。 然而，事实证明，与付款相关的代码之前与个人资料页面代码位于同一位置。因此，两个团队都将他们的代码提取到单独的分支中并重写了集成。 现在的问题是，谁将第一个将他们的更改合并到 分支并假装问题不在他们这边，而另一个团队试图解决由此产生的冲突？  main 基于主干的开发 总之，避免合并冲突是不可能的，但我们当然可以使用以下众所周知的规则使它们更容易解决： 如果一个动作既困难又可怕，就多做几次 在 Git 术语中，这意味着我们需要尽可能频繁地合并（最好是在每次提交时）。当然，在那种情况下，冲突会更频繁地发生，但解决起来会容易得多。 它被称为基于主干的开发，意味着将更改直接推送到 分支，并在不必要时避免使用分支。 main 在上面的示例中，如果两个团队定期将他们的更改推送到 分支，他们会很快注意到他们正在尝试修改同一个文件。 main 更重要的是，他们本可以完全避免问题。考虑到这些更新，第二个团队将在第一个团队已经修改文件后开始进行更改。  细心的读者可能会想：一切听起来都很棒，但我们如何进行测试呢？每个功能的分支允许在发布之前单独测试整个新功能；如果我们不断地将更改集成到 分支中，就没有机会了。 main 引入功能标志 功能标志或功能切换是一个简单的动态标志，允许在运行时切换特定功能。通常，功能标志还允许为特定用户组启用或禁用功能，例如 QA 工程师、员工、特定客户等。  功能标志有几个额外的优点： 无风险部署 直接在生产中进行更可靠的测试 在需要时快速回滚更改。 使用功能标志可以更安全地将更改推送到 分支。当功能标志关闭时，更改不会影响任何人。 main 这种技术允许直接与 分支一起工作或创建短期分支。因此，合并冲突变得非常罕见并且可以迅速解决。 main 结论 总而言之，基于主干的开发与功能标志相结合是一种出色的技术，有助于避免因功能分支中的冲突更改而引发的许多问题。 然而，一如既往，没有一种放之四海而皆准的方法。它适用于在同一个存储库中工作的少数团队——增加这个数量通常需要一些调整。 此外，两种方法总是可以同时使用：根据具体情况和任务使用特性分支或特性标志。

Read My Stories

該音頻是用故事的原始語言製作的！

功能分支是最终的选择吗？

About Author

註釋

標籤

这篇文章刊登在

Related Stories

成功云迁移的完整指南：策略和最佳实践

Claude Sonnet 3.5 系统提示泄漏：法医分析

扬帆起航：利用数据湖开发生产级 RAG 应用程序

如何将您的工作流程提高 10 倍：17 个必备应用程序

成功云迁移的完整指南：策略和最佳实践

Claude Sonnet 3.5 系统提示泄漏：法医分析

扬帆起航：利用数据湖开发生产级 RAG 应用程序

如何将您的工作流程提高 10 倍：17 个必备应用程序

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps