Git - 分支工作流

根据分支的使用方式，可以将它们分成两大类。

• 长期分支

• 短期/主题分支

注意：这只是一个语义上的划分。从技术上（以及实际上）讲，分支只是一个分支，并且始终以相同的方式工作。

长期分支

Git 中的三方合并功能使分支合并随着时间的推移变得更加容易。这些分支在更高层级上使用，独立于单个功能或错误修复开发。

开发人员经常维护多个用于不同开发阶段的长期分支。这包括

• 一个包含可靠代码并准备好发布到生产环境的master分支。

• 一个develop或next分支，它将来自临时分支的可靠功能集成到持续测试和开发中。

这些分支通常代表项目生命周期中的状态，并且可以在项目中保留更长时间（甚至一直保留）。

工作流程包括

• 在短期主题分支上开发功能（例如，auth-module）。

• 将经过测试和稳定的分支合并到next或develop分支中。

分支在分层结构中充当稳定的孤岛。

• 通过测试后，提交会从不稳定的分支迁移到更稳定的分支。

• 一些项目使用其他分支（例如proposed updates(pu)）来集成不太可靠的功能。

• 大型或复杂的项目受益于管理众多长期分支，因为它可以保持稳定性和控制功能集成。

主题分支

每次开始处理新功能或错误修复时，都应该为此主题创建一个新分支。此类分支对于任何规模的项目都很有用，因为它们充当特定任务或功能的临时单元。

与传统的版本控制系统不同，Git 的效率使得在开发过程中可以频繁创建、修改、合并和删除分支。

• 分支通过隔离工作来允许不同的发展，而不会影响主源。

• Git 高效的分支模型能够快速执行分支操作，减少开销，并与各种开发工作流程（如 GitHub Flow 和 Gitflow）无缝集成。

• 之前讨论中使用的分支（例如auth-module和bugfix）在合并到主分支后被删除。

• 此方法将工作划分为特定于主题的分支，并能够快速更改上下文。

• 它简化了更改审查并提高了对更改如何影响代码库的理解。

下图对此进行了说明

在从 master 分支开始后，开发人员会分支出去以处理特定任务（如task A）。

他们可能会创建类似于taskA-v2的分支来测试不同的方法。

通常会返回到 master 分支并在那里完成更多工作。

此外，开发人员会创建实验性分支，如exploratory。

此过程会生成详细描述每个分支的历史记录和用途的提交历史记录。

上图说明了分支过程，并观察到以下几点

• 经过评估，发现taskA-v2是最佳选择，并且根据同事的反馈，exploratory被证明出乎意料地有用。

• 可以安全地放弃原始的taskA分支以及提交 C5 和 C6。

• Exploratory 和taskA-v2可以轻松地集成到主分支中。

• 这种灵活的策略确保有效地处理修改，无论其时间顺序如何。