了解 5 个 Git 工作流程，让我们交付更好的代码并改善开发流程
我还没有见到哪个开发者在看到代码冲突而不沮丧地扯头发的。
解决每个代码冲突是每个开发者都讨厌的事情之一。尤其是当准备进行生产部署时遇到了这种情况！
设置正确的 Git 工作流可以为我们的开发工作流带来很多好处。
当然，拥有正确的 Git 工作流程并不能解决我们所有的问题。但这是朝正确方向迈出的一步。毕竟，团队都是协作工作的，所以在不破坏代码库的情况下一起构建功能是非常重要的。
Git 工作流的设置方式取决于我们正在处理的项目、团队的发布计划、团队的规模等等。
在本文中，将介绍 5 种不同的 Git 工作流程，它们的优点、缺点以及何时使用它们。
让我们开始吧！
1. 基本的 Git 工作流
最基本的 Git 工作流是只有一个分支的分支 —— master 分支。
开发人员直接向它提交代码，并使用它来部署到生产环境。
通常不建议使用此工作流，除非您处理的是一个边缘项目，并且希望快速开始。
由于只有一个分支，因此这里实际上没有任何过程，这使得开始使用 Git 很容易。
但是，使用此工作流时需要记住的一些缺点是：
在代码协作上将频繁遇到冲突
将有缺陷的软件交付到生产环境的可能性更高
维护干净的代码更加困难
2. Git 功能分支工作流
当有多个开发人员在同一个代码库上工作时，使用 Git 功能分支工作流将成为一个必须的工作。
假设一个开发者正在开发一个新特性，另一个开发者正在开发第二个功能。现在，如果两个开发者都在同一个分支中工作并向其添加提交代码，这将使代码库变得一团糟，并产生大量冲突。
为了避免这种情况，两个开发者可以从 master 分支创建两个独立的分支，并分别处理各自的功能。
当他们完成了他们的功能之后，他们可以将他们各自的分支合并到 master 分支，并且不必等待另一个功能完成就可以进行部署。
使用此工作流的优点是，它可以使您可以在代码上进行协作，而不必担心代码冲突。
3. 带有 develop 分支的 Git 功能分支工作流
此工作流是开发团队中比较流行的工作流之一。
它与 Git 功能分支工作流相似，但它有一个与 master 分支并行进行的 develop 分支。
在此工作流中，master 分支始终反映生产就绪状态。每当团队想要部署到生产环境时，都会从 master 分支进行部署。
develop 分支包含要交付到下一个版本的开发变更的内容。
开发人员从 develop 分支创建分支并开发新功能，一旦功能开发完成后，将对其进行测试，然后合并到 develop 分支并使用 develop 分支的代码进行测试，最后合并到 master 分支。
该工作流程的优势在于，它使团队能够一致地合并新功能、进行测试，并部署到生产环境中。
虽然维护代码更容易了，但是对于某些团队来说，这可能会让人觉得有些厌烦，因为这可能会让人觉得要经历一个乏味的过程。
4. Gitflow 工作流
Gitflow 工作流与我们前面讨论的工作流非常相似，我们将其与另外两个分支结合使用 —— release 分支和 hot-fix 分支。
hot-fix 分支
hot-fix 分支是直接从 master 分支创建的分支，并且直接合并到 master 分支而不是 develop 分支。
它仅在必须快速修补生产问题时使用。
此分支的一个优点是，它使您可以快速解决生产问题，而不必中断其他人的工作流，也不必等待下一个发布周期。
将修订合并到 master 分支并进行部署后，应将其合并到 develop 和当前 release 分支。这样做是为了确保从 develop 分支创建的新功能分支都拥有最新的代码。
release 分支
在发布计划中的所有功能都北成功合并到 develop 分支之后，从 develop 分支创建 release 分支。
与新功能无关的代码不会被添加到 release 分支中，只有与发布相关的代码才会添加到 release 分支。例如，文档、错误修复和其他与此版本相关的任务都会添加到此分支中。
一旦将此分支与 master 分支合并并部署到生产环境中，它也会合并回 develop 分支，以便在创建一个新功能分支时，它拥有有最新的代码。
这个工作流程最早由 Vincent Driessen 在 2010 年发布并广受欢迎，自那时起，它已被具有确定发布周期的组织广泛使用。
反思笔记（Vincent Driessen，2020.3.5）
这种模型是在 2010 年构思出来的，而现在距今已有 10 多年的历史，而 Git 本身诞生后不久。在那 10 年中，git-flow（本文介绍的分支模型）在许多软件团队中非常流行，以至于人们开始将其视为某种标准，但不幸的是，它也被当作教条或灵丹妙药。
在那 10 年中，Git 本身席卷了整个世界，并且与 Git 一起开发的最受欢迎的软件类型正越来越多地转向 Web 应用程序 —— 至少在我的过滤泡（filter bubble）中。Web 应用程序通常是连续交付的，不会回滚，并且您不必支持在市面上运行的软件的多个版本。
这不是我十年前写博客时想到的那种软件。如果您的团队正在持续交付软件，我建议您采用更简单的工作流程（例如 GitHub flow），而不是尝试将 git-flow 引入您的团队。
但是，如果您正在构建明确版本控制的软件，或者如果您需要支持软件的多个版本，那么 git-flow 可能仍然适合您的团队，就像它在过去的那 10 年一样。如果是这样的话，请继续阅读。
总而言之，永远记住灵丹妙药是不存在的。考虑你自己的情况，自行决定。
5. Git Fork 工作流
Fork 工作流在使用开源软件的团队中很流行。（其实就是前边 Vincent Driessen 在反思笔记里提到的 GitHub flow）
该流程通常如下：
开发者 fork 开源软件的官方存储库，在他们的帐户中创建此存储库的副本
然后开发者将存储库从其帐户克隆到本地系统
将官方存储库的远程地址添加到克隆到本地系统的存储库中
开发者在本地系统中创建一个新的功能分支，在该分支进行更改并提交代码
这些更改和分支一起被推送到开发者帐户上的存储库的副本中
从该功能分支发起一个 pull request 提交到官方存储库
官方存储库的管理者会检查更改，并批准更改以合并到官方存储库中
你正在使用哪个 Git 工作流呢？欢迎下方评论讨论~
参考：