共计 4283 个字符，预计需要花费 11 分钟才能阅读完成。
明天跟大家分享一点鹅厂程序员的 Git 应用教训。
介绍四种工作流来更好地了解 Git 的我的项目应用流程，利用其弱小的分支性能为本人的我的项目构筑适配的工作流。
1. 前言
开发人员在日常开发过程中，不可避免地会应用到代码的版本控制工具，如 svn、git 等等，记得在刚刚入职的时候，部门应用的次要的 VCS 工具还是 svn，期间有着十分苦楚的 download 经验，下载一份仓库花了我 2-3 个小时，相比于 svn，git 有着十分多的劣势，比方仓库 clone 速度十分快、外围的分支性能等等，后续公司也在推应用 git 来保护代码仓库，齐全摒弃轻便的 svn。
那么，切换到 git 来保护代码仓库，会对咱们的日常开发造成影响吗？许可是显然的，首先咱们须要学习 git 的基本概念与用法，而后就须要咱们在具体的我的项目实际过程中打磨咱们的 git 应用技巧，比方灵便的分支、子模块应用等等，对于 git 概念或技术上的介绍，本文不予开展，如果对 git 实现上的细节感兴趣的话，能够自行搜寻学习。
接下来次要跟大家探讨的主题是 git 工作流，git 初学者可能对这个概念并不是很清晰，脑海中想到的可能是 git 的工作原理之类的，其实并不是的，git 工作流指的是多人合作过程中的 git 的应用流程，不波及技术细节，是一种项目管理、开发约定的形式。有些同学可能感觉习得了 git 三板斧（clone、add commit、push）就算是实现了对 git 的开发认知，其实咱们可能还停留在最原始的设想之中。
2. 集中式工作流
集中式工作流，这种工作形式对于应用过 svn 的同学想必会十分的相熟，让咱们思考下在 svn 下的合作体验，不同的开发同学须要顺次将本地的批改提交到服务器，如果有抵触就先解决本地的抵触再提交，这个过程中远端的服务器就像是一个集中管理者，治理着所有人的代码提交，所以 svn 的开发合作流程就是典型的集中式工作流，那切换到 git 场景下，集中式工作流的工作形式又是什么样的呢？
首先咱们看下 git 的根底操作框架，如图 2.1 所示：
这里有一份地方仓库，是寄存我的项目代码的中央，三个开发人员 A、B、C 别离在本地持有一份地方仓库的拷贝 – 本地仓库，这里相比于 svn 的框架只是多了一个本地仓库；
接下来咱们再来看在我的项目开发进行了一段时间之后的提交日志是什么样的，如图 2.2 所示：
这里是一条最简略的 master 分支上的提交日志记录，那相比于 svn 的框架有啥区别呢，只有把 master 分支字样改成 trunk 就变成了一条 svn 的提交记录。
最初，咱们思考以下几个条件：
1、有无本地仓库 2、默认分支是 master 还是 trunk3、提交操作应用 git command 还是 svn command（细节疏忽）
咱们能够看出 svn 下的集中式工作流同样实用于 git，只有大家把 svn 相干的概念全副切换到 git 下即可：1、意识本地仓库 2、意识默认分支 master3、应用 git 的提交命令
以上三点中的前两点对于集中式工作流下的开发者其实是通明的，开发者只须要将提交命令改成 git 就能够无缝连接 svn 下的集中式工作流！
所以，svn 切换到 git 的老本其实还是很低的，只须要你把握 git 的根底提交命令！
git 下的集中式工作流，是一种只应用 master 主分支的开发方式，这种形式简单明了，然而毛病是不同开发人员的提交日志混淆在一起，难以定位问题。
3. 性能分支工作流
性能分支工作流，这种工作形式是以集中式工作流为根底，再为不同性能开发调配独自的性能分支来进行的；这种工作流的骨干分支依然是 master 分支，然而开发者在进行日常需要开发时不能将代码间接提交到 master 分支上，个别是为特定的需要新建一个性能分支，并且取一个具备描述性的名字，例如：feat-personal-page、issue-#1702，描述性的名称能够让其余开发者疾速地明确这个性能分支的次要作用，进步不同开发者之间的协同效率；性能分支性能流的提交日志记录如图 3.1 所示：
从图中能够看出，相比于集中式工作流，分支历史看起来更加简洁、正当，让不同性能的开发进行隔离，防止不同性能代码之间产生不利的影响。
此外，在性能分支上的需要开发实现之后，咱们须要将分支合并到骨干分支 master 上，这时候须要进行的操作是 pull request，为什么要进行 PR 操作，而不是间接进行代码的 merge 呢，这里首先须要大家意识 PR 是什么操作，其次须要大家理解 PR 操作的意义；
性能需要开发实现之后，须要将本地性能分支推送到地方仓库的性能分支上，而后在地方仓库的性能分支上发动一个 pull request 申请去将性能分支上的批改合并到 master 分支上，这个过程个别是在 GIT 的我的项目主页上进行，公司外部就工蜂的我的项目主页，如图 3.2 所示，是 flutter 我的项目的某一次 PR 详情：
PR 操作给我的项目带来的好处有两点：1、code review2、探讨代码的公共平台
前者是每次 PR 操作产生时会告诉相关者来查看待合并的代码，在查看过程中即实现了对代码的检视，这个过程保障了 master 分支上的已合并代码的健壮性；后者则是因为每次 PR 都会有一个 PR 详情主页，如图 3.2，每一个开发者都能够针对代码的实现提出本人的意见，使得探讨代码变成更加便捷高效，且为代码变更回顾提供了可能。
性能分支工作流是 git 我的项目开发非常灵活应用的一种形式，然而对于大型的我的项目而言，须要为不同的分支调配更加具体的角色。
4.Gitflow 工作流
Gitflow 工作流是目前十分成熟的一个计划，它定义了一个围绕我的项目公布的严格分支模型，通过为代码研发、我的项目公布以及保护调配独立的分支来让我的项目的迭代过程更加地顺畅，不同于之前的集中式工作流以及性能分支工作流，gitflow 工作流常驻的分支有两个：骨干分支 master、开发分支 dev，此外针对我的项目研发的各个阶段，设定了特定的分支。
阶段分支常驻 master、dev 研发 feature 热修复 hotfix 公布 release
首先针对常驻分支，如图 4.1
常驻分支示意在我的项目提交历史中始终存在的分支，这里 master 分支次要跟踪我的项目正式公布的代码历史，dev 分支次要跟踪我的项目代码研发的提交历史；此外在 master 分支上通常会为某次版本公布调配一个标签来记录版本号，这为当前我的项目排查定位提供便当。
接下来，咱们来看 gitflow 工作流中，代码研发阶段的工作流程。
如图 4.2 所示，开发阶段开启某一个需要时须要从 dev 分支上新建性能分支 feature，图中所示为两个 feature 分支，代表同时有两个性能在开发中，这里的 feature 分支应用跟性能分支工作流中的应用形式是一样的，在需要开发实现之后须要提交 PR 申请合并进 dev 分支，实现之后即可删除对应的性能分支。
很多时候，在需要研发过程中，线上的代码可能会呈现问题，这时候须要咱们进行及时的修复，这就是我的项目迭代过程中的热修复阶段。
如图 4.3 所示，假如咱们在开发的过程中线上呈现了一个 bug，这时候咱们须要从 master 的标签 v0.1 上检出一份分支代码 hotfix，修复并验证好了之后，须要将 hotfix 代码别离合并到 master /dev 分支上，并在 master 的提交上打上一个标签 v0.2，这里须要将热修复的代码别离合并进两个常驻分支是因为须要保障两边代码的一致性。
最初，咱们来看下我的项目迭代的公布阶段，咱们须要将之前性能开发实现的个性公布到线下来，如图 4.4 所示
首先在 dev 分支的提交处新建 release 分支，在这个分支上进行 bug 修复、面向公布的一些工作，这个分支不做任何性能上的工作，实现之后将 release 分支再别离合并进 master/dev 分支，并在 master 提交上打上标签 v1.0，这样一个公布阶段的代码操作就实现了
最初咱们来看公布之后的目前的日志记录状况，如图 4.5 所示，这里能够将没有用的分支 hotfix、release、feature 均删除了，能够看出咱们的常驻分支就 master/dev，最上面的 feature 示意仍在开发中。
gitflow 工作流是目前比拟很成熟的计划，它的长处有：
1、公布迭代流程更顺畅 2、使得代码有了更加谨严的我的项目构造，不便定位排查问题
大型的我的项目 / 迭代速度快的举荐应用这种工作流程！
5.Forking 工作流
最初介绍一种开源我的项目罕用的工作流 ——Forking 工作流，介绍之前首先须要理解什么是 fork 操作，如图 5.1 所示
fork 操作是在集体近程仓库新建一份指标近程仓库的拷贝，操作很简略，比方 github 上在我的项目的主页点击 fork 按钮即可。
明确了 fork 操作之后，咱们来看下 forking 工作流的流程，如图 5.2 所示：
首先开发者 A 领有一个远端仓库，这时候有一个开发者 C 也想参加 A 的这个我的项目的开发工作，那他就能够 fork 一份 A 的这个仓库，之后在 c 的集体仓库里就有了这份代码库，后续开发者 C 就能够在本人的这个我的项目里进行开发工作，c 在实现了某个性能的实现之后，能够给 A 的仓库发一个 PR 申请，这时候会告诉到开发者 A 有新的 PR，A 如果有问题能够间接在这个 PR 里提，开发者 C 能够进行进一步的批改，最初 A 通过了 C 的这份 PR 申请，就会将 C 的代码合并进 A 的仓库，这样就实现了 A / 代码库新个性的开发。同时如果有其余开发者对 A 的我的项目有趣味也会进行雷同的操作。
这里留神到 开发者 B/C 并不是 A 代码库的开发人员，而是第三方开发者，所以这种工作流次要用于开源我的项目！
6. 总结
最初回顾下这几种 git 工作流，集中式工作流能够说是 git 工作流的根底，初学者能够无缝地从 svn 的模式切换到 git 的模式；性能分支工作流在集中式的根底上又引入了性能分支，灵便地利用了 git 的分支个性，性能拆散 / PR 优化了日常工作的效率；gitflow 工作流则是为大型项目的迭代过程服务的，指定了一个严格的分支模型，使得迭代流程更加顺畅；forking 工作流则是开源我的项目的首选，想要为开源我的项目做奉献就必须要懂得这种工作流！
当然，以上形容的这些工作流并不是理论工作中 git 应用的准则，这只是一些举荐的应用形式，在具体的我的项目研发过程中，咱们须要联合我的项目以及团队现状作出取舍，总结出适宜本人团队的工作流，能力让 git 更好地为咱们服务！
起源：腾讯技术工程
欢送关注我的微信公众号「码农解围」，分享 Python、Java、大数据、机器学习、人工智能等技术，关注码农技术晋升•职场解围•思维跃迁，20 万 + 码农成长充电第一站，陪有幻想的你一起成长
