摘要:本文介绍了一种规范的Git分支管理方法,旨在帮助团队高效地协作开发。
git介绍
Git 是一个分布式的版本管理工具。
中心式协同工作流
首先,先说明一下,Git 是可以像 SVN 这样的中心工作流一样工作的。
这个过程一般是下面这个样子的:
- 从服务器上做git pull origin master把代码同步下来。
- 改完后,git commit到本地仓库中。
- 然后git push origin master到远程仓库中,这样其他同学就可以得到你的代码了。
如果在第 3 步发现 push 失败,因为别人已经提交了,那么你需要先把服务器上的代码给 pull 下来,为了避免有 merge 动作,你可以使用 git pull –rebase 。这样就可以把服务器上的提交直接合并到你的代码中。
对此,Git 的操作是这样的:
- 先把你本地提交的代码放到一边。
- 然后把服务器上的改动下载下来。
- 然后在本地把你之前的改动再重新一个一个地做 commit,直到全部成功。
如下图所示。Git 会把 Origin/Master 的远程分支下载下来(绿色的),然后把本地的 Master 分支上的改动一个一个地提交上去(黄色的)。
如果有冲突,那么你要先解决冲突,然后做 git rebase –continue 。如下图所示,git 在做 pull –rebase 时,会一个一个地应用(apply)本地提交的代码,如果有冲突就会停下来,等你解决冲突。
功能分支协同工作流
上面的那种方式最大的问题就是代码可能干扰太严重。尤其是,我们想安安静静地开发一个功能时,我们想把各个功能的代码变动隔离开来,同时各个功能又会有多个开发人员在开发。
这时,我们不想让各个功能的开发人员都在 Master 分支上共享他们的代码。我们想要的协同方式是这样的:同时开发一个功能的开发人员可以分享各自的代码,但是不会把代码分享给开发其他功能的开发人员,直到整个功能开发完毕后,才会分享给其他的开发人员(也就是进入主干分支)。
因此,我们引入“功能分支”。这个协同工作流的开发过程如下:
- 首先使用 git checkout -b new-feature 创建 “feature_20220318”分支。
- 然后共同开发这个功能的程序员就在这个分支上工作,进行 add、commit 等操作。
- 然后通过 git push -u origin feature_20220318 把分支代码 push 到服务器上。
- 其他程序员可以通过git pull –rebase来拿到最新的这个分支的代码。
- 最后通过 Pull Request 的方式做完 Code Review 后合并到 Master 分支上。
就像上面这个图显示的一样,绿色的分支就是功能分支,合并后就会像上面这个样子。
我们可以看到,其实,这种开发也是以服务器为中心的开发,还不是 Git 分布式开发,它只不过是用分支来完成代码改动的隔离。
另外,我想提醒一下,为什么会叫“功能分支”,而不是“项目分支”?因为 Git 的最佳实践希望大家在开发的过程中,快速提交,快速合并,快速完成。这样可以少很多冲突的事,所以叫功能分支。
传统的项目分支开得太久,时间越长就越合不回去。这种玩法其实就是让我们把一个大项目切分成若干个小项目来执行(最好是一个小功能一个项目)。
这样才是互联网式的快速迭代式的开发流程。
GitFlow 协同工作流
在真实的生产过程中,前面的协同工作流还是不能满足工作的要求。这主要因为我们的生产过程是比较复杂的,软件生产中会有各式各样的问题,并要面对不同的环境。
我们要在不停地开发新代码的同时,维护线上的代码,于是,就有了下面这些需求:
- 希望有一个分支是非常干净的,上面是可以发布的代码,上面的改动永远都是可以发布到生产环境中的。这个分支上不能有中间开发过程中不可以上生产线的代码提交。
- 希望当代码达到可以上线的状态时,也就是在 alpha/beta release 时,在测试和交付的过程中,依然可以开发下一个版本的代码。
- 最后,对于已经发布的代码,也会有一些 Bug-fix 的改动,不会将正在开发的代码提交到生产线上去。
面对这些需求,前面的那些协同方式就都不行了。因为我们不仅是要在整个团队中共享代码,我们要的更是管理好不同环境下的代码不互相干扰。说得技术一点儿就是,要管理好代码与环境的一致性。
为了解决这些问题,GitFlow 协同工作流就出来了。这个协同工作流的核心思想如下图所示:
整个代码库中一共有五种分支。
- Master 分支:主干分支,用作发布环境,上面的每一次提交都是可以发布的。
- Feature 分支:功能分支,用于开发功能,其对应的是开发环境。
- Developer 分支:开发分支,一旦功能开发完成,就向 Developer 分支合并,合并完成后,删除功能分支。这个分支对应的是集成测试环境。
- Release 分支:当 Developer 分支测试达到可以发布状态时,开出一个 Release 分支来,然后做发布前的准备工作。这个分支对应的是预发环境。之所以需要这个 Release 分支,是我们的开发可以继续向前,不会因为要发布而被 block 住而不能提交。 一旦 Release 分支上的代码达到可以上线的状态,那么需要把 Release 分支向 Master 分支和 Developer 分支同时合并,以保证代码的一致性。然后再把 Release 分支删除掉。
- Hotfix 分支:是用于处理生产线上代码的 Bug-fix,每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支,完成后,向 Developer 分支和 Master 分支上合并。合并完成后,删除 Hotfix 分支。
这就是整个 GitFlow 协同工作流的工作过程。我们可以看到:
- 我们需要长期维护 Master 和 Developer 两个分支。
- 这其中的方式还是有一定复杂度的,尤其是 Release 和 Hotfix 分支需要同时向两个分支作合并。所以,如果没有一个好的工具来支撑的话,这会因为我们可能会忘了做一些操作而导致代码不一致。
- GitFlow 协同虽然工作流比较重。但是它几乎可以应对所有公司的各种开发流程,包括瀑布模型,或是快速迭代模型。
简化版 GitFlow 协同工作流
由于 GitFlow 协同工作流比较重,不太适合我们现在的团队情况,所以基于 GitFlow 协同工作流做出以下简化:
1、分支构成
- Master 分支:主干分支,用作发布环境,上面的每一次提交都是可以发布的。
- Feature 分支:功能分支,用于开发功能,其对应的是开发环境。
- Release 分支:当 Feature 分支达到可以提测状态时,需要将代码合并到 Release 分支。这个分支对应的是测试、预发环境。之所以需要这个 Release 分支,是我们的开发可以继续向前,不会因为要发布而被 block 住而不能提交。 一旦 Release 分支上的代码达到可以上线的状态,那么需要把 Release 分支向 Master 合并,以保证代码的一致性。然后再把 Release 分支删除掉。
- Hotfix 分支:是用于处理生产线上代码的 Bug-fix,每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支,完成后,向 Master 分支上合并。合并完成后,删除 Hotfix 分支。
2、命名规则
分支类型 + 上线日期 + 负责人简称(分支创建人)
例如:
1 | Feature分支,20220318日上线,创建人陈杰 |
3、开发步骤
①正常需求开发
步骤一:一个新需求开始后,基于 Master 分支创建一个 Feature 分支,例如 feature_20220320_cj。
步骤二:当 Feature 分支的代码,自测、联调结束并且达到可以提测的状态后,基于 Master 分支创建一个 Release 分支,例如:release_20220320_cj。
步骤三:当测试同学测试通过后,将 Release 分支的代码合并到 Master 分支,并发布上线。如果测似过程中,发现 bug,则开发人员重复步骤 一、二,直到达到可以上线的标准为止。
②线上问题紧急修复
步骤一:当线上出现 bug ,需要紧急修复时,基于 Master 分支创建一个 Hotfix 分支,例如 hotfix_20220320_cj。
步骤二:当测试同学测试通过后,将 Hotfix 分支的代码合并到 Master 分支,并发布上线。如果测似过程中,发现 bug,则开发人员重复步骤一。
③不同人员在同个 git 仓库进行功能开发
参考①正常需求开发,区别点:
区别一:每个人员根据自己独立的功能模块,基于 Master 分支创建一个 Feature 分支,例如 feature_20220320_cj and feature_20220320_zs。
区别二:需要创建一个共同的 Release 分支,例如 release_20220320_saas3,当每个人员自己的功能模块达到可以提测状态后,将自己的代码提交到 Release 分支。
区别三:测试同学可以根据提测的不同的功能模块,进行测试,但是在最后代码都提交完毕后,还需要进行一次系统测试,确保合并后的代码是正确的(保证代码正确性)。
- 本文作者: th3ee9ine
- 本文链接: https://www.blog.ajie39.top/2023/05/28/Git分支规范/
- 版权声明: 本博客所有文章除特别声明外,均采用 LICENSE 下的许可协议。转载请注明出处!