Git-flow 非技术入门。

照片由Yancy Min拍摄，来自Unsplash

DEV 团队的各位好！

我们都听说过这样的建议和最佳实践：“为你的项目使用版本控制。” 虽然这没错，它或许能帮你避免犯错，但很少有博客在宣传使用版本控制时提到如何使用它，或者最佳使用方法。

Git-flow 来了！Git-flow 是一种 Git 工作流，可以用来简化整个应用程序的版本控制流程。在今天的文章中，我将介绍 Git-flow 的基础知识以及它如何改进你的 Git 工作流程。

什么是git-flow？

Git-flow 是 2010 年由这篇文章提出的 Git 工作流。该工作流旨在帮助您进行软件开发和 DevOps 实践。Git-flow 为您的软件定义了分支策略和发布管理。

Git-flow 以 Git 为基础（顾名思义！）。Git 因其分布式特性和“易用性”而被提出。与其他一些版本控制系统相比，Git 提供了更简单的分支和合并机制。更多关于Git 的信息请点击此处。

Git-flow 分支

创建项目并启用 Git 后，默认情况下会有一个主分支（不妨试试，别害羞）。在 Git 工作流程中，这个主分支的 HEAD（最新提交的更改）应该始终包含可用于生产环境的软件。

你可能会问：如果主分支用于存放生产环境可用的代码，那我应该在哪个分支上开发应用程序呢？你猜对了！你的主要开发分支叫做develop。develop分支应该始终包含最新的、可以发布（可以部署到生产环境）的更改。

来源

为了确保你的开发分支只包含可以部署到生产环境的代码，你需要将开发过程分成多个阶段，最终实现发布。而git-flow正好能解决这个问题。

Git-flow 由三种类型的分支组成：

• 特征分支
• 发布分支
• 热修复分支

从技术层面来说，每个分支都与其他分支相同。但为了区分用途，每种类型的分支都有其特定的用途，并且对其来源分支（可以从哪个分支分支出来）和合并目标（可以合并到哪个分支）都有严格的规则。

来源

特征分支

特性分支用于开发各种功能。例如，你想开发软件的登录功能吗？那就应该在特性分支上进行开发。你可以使用特性分支来开发想要添加到软件中的功能，无论是用于新版本还是未来的版本（也许你只是想为后续的开发和发布奠定基础）。

特性分支应该始终从开发分支创建。为什么？这样你才能使用最新版本进行开发。同样，特性分支应该始终合并到开发分支，这样才能确保特性已准备好发布。

发布分支

发布分支的作用是在正式发布前进行最后的调整和完善。在这些分支上，你可以进行一些小的修复和最终的调整。如果你的开发分支已经包含了最新的代码，为什么还要使用发布分支呢？

很高兴你问了这个问题（即使你没问），这样做是为了将发布和并行开发分开。假设你同时完成了三个功能（并将它们合并到了开发分支），但你只想发布其中一个。你可以为这个特定功能创建一个发布分支，进行最后的调整，然后将其合并到主分支。轻而易举，你既实现了功能的发布，又保持了开发分支可以接收来自新功能的更改。

由于您正在处理已准备好发布的代码，因此只能从develop分支创建发布分支。完成分支后，您必须将其合并到主分支并发布代码，同时也要将其合并到develop分支（以便 develop 分支拥有最新的更改）。

热修复分支

最后，我们还有热修复分支。它们的功能与发布分支相同，都是为了让代码做好生产准备，但它们专门用于计划外的更改/改进。

想象一下，你对软件进行了全面测试，涵盖了所有可能出现故障的主要方式，并且软件全部通过了测试，你发布了新功能。然而，发布后仅仅一两天，用户就开始抱怨点击按钮时得到的是 X 而不是 Y。

要修复这个 bug，你不需要创建一个特性分支，然后将其合并到开发分支，再创建一个发布分支。不！你应该从主分支创建一个热修复分支来修复这个 bug，所以才叫热修复分支。修复代码中的 bug 后，你必须将更改合并到开发分支和主分支，以便用于生产环境。

好了，以上就是 Git-flow 的全部内容。Git-flow 是一种非常严格的项目版本控制工作流程，对某些人来说，它可能显得过于复杂且令人望而生畏。我的建议是不要完全照搬 Git-flow 的规则，而是取其精华，并根据实际情况灵活调整，最终构建出一个你和你的团队能够轻松协作并集成到项目中的开发架构。

希望这篇文章对你有所帮助。继续努力，规划你的副业项目吧！🤟