07 | 工作流设计：如何设计合理的多人开发模式？

孔令飞



该思维导图由 AI 生成，仅供参考

你好，我是孔令飞。今天我们来聊聊如何设计合理的开发模式。
一个企业级项目是由多人合作完成的，不同开发者在本地开发完代码之后，可能提交到同一个代码仓库，同一个开发者也可能同时开发几个功能特性。这种多人合作开发、多功能并行开发的特性如果处理不好，就会带来诸如丢失代码、合错代码、代码冲突等问题。
所以，在编码之前，我们需要设计一个合理的开发模式。又因为目前开发者基本都是基于 Git 进行开发的，所以本节课，我会教你怎么基于 Git 设计出一个合理的开发模式。
那么如何设计工作流呢？你可以根据需要，自己设计工作流，也可以采用业界沉淀下来的、设计好的、受欢迎的工作流。一方面，这些工作流经过长时间的实践，被证明是合理的；另一方面，采用一种被大家熟知且业界通用的工作流，会减少团队内部磨合的时间。在这一讲中，我会为你介绍 4 种受欢迎的工作流，你可以选择其中一种作为你的工作流设计。
在使用 Git 开发时，有 4 种常用的工作流，也叫开发模式，按演进顺序分为集中式工作流、功能分支工作流、Git Flow 工作流和 Forking 工作流。接下来，我会按演进顺序分别介绍这 4 种工作流。
集中式工作流我们先来看看集中式工作流，它是最简单的一种开发方式。集中式工作流的工作模式如下图所示：

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了Git工作流设计，包括集中式工作流、功能分支工作流、Git Flow工作流和Forking工作流。集中式工作流适合小团队和小项目，但容易导致代码管理混乱；功能分支工作流通过PR流程提高代码质量；Git Flow适合大型项目或迭代速度快的项目；Forking工作流适用于开源项目和开发者不固定的场景。选择合适的开发模式有助于提高团队协作效率和代码质量。文章还提供了针对Git Flow工作流的课后练习，帮助读者深入理解工作流的操作步骤。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Go 语言项目开发实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(49)

最新
精选

Geek_c3e438
哈哈哈哈，上文刚说了commit规范，这篇就随意了，当然知道仅做演示，开个玩笑~
作者回复: 是的，这里主要是演示工作流个演示。这里没有按commit message规范写的原因如下： 1. 根据我的研发经验，很多时候，规范对大多数开发者是用来看的，所以如果制定了commit message规范，需要有相应的工具，来强约束大家遵守这个规范，因为是演示所以没搞这么复杂。 2. IAM项目的commit 都是符合规范的，里面有工具强约束，可以看下。老哥看的很细，是个优化点，今后避免。
2021-06-08
2
28
💎A
用source tree 一键git flow.
作者回复: 牛批!
2021-06-08
2
10
我来也
看的比较过瘾。这些git命令，我一般都用zsh里面git插件的缩写来完成。说白了就是一批alias命令。比如gcb切分支，gsta保存修改到堆栈，gstp恢复堆栈中的修改，gpsup新建远端分支。grb变基，grh 软重置，grhh硬重置等等。
作者回复: 优秀！
2021-07-05

7
byemoto
如何保证develop和master分支不会产生冲突呢？
作者回复: 他俩不会冲突的吧，有冲突在merge到develop的时候就解决了
2021-06-30

7
forever_ele
说一下我这边的Git工作流经验：我们会预设三个常驻分支，分别是 Prod-生产分支、Pre-Prod-预发布分支、Dev-开发分支，master保留分支未使用。当有新功能需要开发时，首先是从prod分支进行拉取个人开发分支，因为此时dev可能会有其他同学开发的其他需求代码，但实际发布时间未知，为了避免新功能发布时包含其他需求代码所以要从prod分支新建个人开发分支，保证分支是“干净的”。个人本地开发测试后合并dev分支进行线上测试，没有问题再将分支合并至pre交付客户或非技术部门进行uat测试。最后将个人开发分支合并prod进行发布。
作者回复: 流程很清晰呀
2021-08-06

5
Alery
请问Forking 工作流中git rebase upstream/master 这一步是做什么？
作者回复: 合并master分支的代码，跟git merge相比，可以避免很多自动生成的merge记录
2021-06-09
3
5
types
看了git flow， tag都是在master上标记的，看起来只支持单个发行版本。如果我需要维护多个发行版本，多个发行版本有共性需求，也有各自的定制化需求，请问这个时候应该以什么样的流程进行开发？
作者回复: tag是不区分branch的。比如你在develop分支打了v1.0.0 tag，切换到v1.0.0 tag时，git会自动切换到develop分支的v1.0.0 tag。如果要维护多个发行版，可以分多个repo，但不好管理。建议这么来：基础版本分支: master 发行版A： masterA/feature/xxx masterA/develop 发行版B： masterB/feature/xxx masterB/develop
2021-07-30
2
3
崔子昂
很多公司会用Jira这种issue管理系统，而branch name用issue code的话，会有一些联动性的功能，比较纠结如果用功能名的话，就失去这个方便的地方了。
作者回复: 可以根据需要自己指定branch名规范，如果有这种联动性需求，其实也可以适配
2021-06-28

3
theseusv
催更催更~
作者回复: 我们加油
2021-06-08

3
Juniper
看完这篇文章，受益匪浅。不过有个疑问，如果采用git flow模式，提测的时候提release分支测试的，如果我有一个release1.0.0的分支在测试中，这个时候又有新的开发任务了，从develop分支切出来，此时的develop分支代码只经过开发测试，还非常不稳定，对于新的feature分支影响还是比较大的，怎么解决。严格安照串行的方式是没有问题的，release1.0.0验证完成，master develop merge完成发布，然后在开始进入下个功能的开发。但是现实场景很容易出现，上一个版本还是测试阶段，就有别的开发任务了
作者回复: 好问题。等release1.0.0分支的修复合并到develop分支后，后来新建的分支再rebase下develop分支就可以了。
2021-09-24

2

收起评论