鹅厂是如何使用 Git 的？

最新推荐文章于 2025-11-29 06:30:00 发布

原创最新推荐文章于 2025-11-29 06:30:00 发布 · 631 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#git

程序员专栏收录该内容

821 篇文章

订阅专栏

本文详细介绍了Gitflow工作流程中的PullRequest操作及其在代码审查和项目协作中的作用。重点阐述了功能分支开发完成后如何通过PR合并到主分支，并强调了PR在保证代码质量和团队讨论中的价值。同时对比了Gitflow与其他工作流的区别，推荐大型项目采用Gitflow以提高迭代效率和代码结构严谨性。

此外，在功能分支上的需求开发完成之后，我们需要将分支合并到主干分支 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 代码库的开发人员，而是第三方开发者，所以这种工作流主要用于开源项目！
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

写在最后

作为一名即将求职的程序员，面对一个可能跟近些年非常不同的 2019 年，你的就业机会和风口会出现在哪里？在这种新环境下，工作应该选择大厂还是小公司？已有几年工作经验的老兵，又应该如何保持和提升自身竞争力，转被动为主动？

就目前大环境来看，跳槽成功的难度比往年高很多。一个明显的感受：今年的面试，无论一面还是二面，都很考验Java程序员的技术功底。

最近我整理了一份复习用的面试题及面试高频的考点题及技术点梳理成一份“Java经典面试问题（含答案解析）.pdf和一份网上搜集的“Java程序员面试笔试真题库.pdf”（实际上比预期多花了不少精力），包含分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货！

由于篇幅有限，为了方便大家观看，这里以图片的形式给大家展示部分的目录和答案截图！