Git Branch Guidelines

date
Dec 25, 2020
slug
git-branch-guidelines
status
Published
tags
Git
Code Spec
summary
type
Post

我们日常开发面临的问题


  • 紧急修复线上BUG,应该如何拉取代码进行改动,直接在develop或master改吗?
  • 现在团队有好几个并行开发任务,每个上线时间点不一样,而且是不同的小组负责开发,怎么管理并行任务,如何推送正确代码是一个大问题。
  • 每个人对于分支命名不一样,对于命名的理解也千差万别,上线前在发现,分支合并错了。

分支管理的目标


  • 代码提交在应该提交的分支
  • 随时可以切换到线上稳定版本代码
  • 多个版本的开发工作同时进行
  • 明确每个分支的功用,做到对应的分支执行对应的操作
  • 使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

有一份前辈的参考资料


A successful Git branching model By Vincent Driessen on Tuesday, January 05, 2010
首先这个不是Git或Github的官方资料,只是这位前辈的个人总结,也仅仅是适用当时这位前辈所在的Team的工作模式,并不适用与目前团队的工作模式。所以,在参考Git Flow的资料后,我们制定了自己的团队规范。

我们的规范


notion image
feature/sprintXX
  • 作用:新功能迭代开发
  • 部署环境:开发环境 DEV
  • 创建:基于develop分支
  • 是否删除:功能发布后删除
  • 限制:无
test/sprintXX
  • 作用:新功能迭代测试
  • 部署环境:测试环境(FAT)
  • 创建:基于feature分支(每次提测前,feature merge develop代码,feature再合并到test)
  • 是否删除:功能发布后删除
  • 限制:No Push / 开发人员Merge
hotfix/yyyyMMdd
  • 作用:线上问题修复
  • 部署环境:测试环境(FAT)
  • 创建:master分支(修复上线后,合并回master和develop)
  • 是否删除:修复发布后删除
  • 限制:无
develop
  • 作用:包含最新的功能代码,新建feature/sprintXX 分支的基础
  • 限制:No Push / 开发人员Merge
master
  • 作用:稳定代码
  • 部署环境:生产环境(PROD)
  • 限制:No Push / 少部分有权限的可Merge

分支操作规范


feature/sprintXX分支下使用rebase

解决提交路线图清晰问题,git pull默认是merge操作,可以使用如下命令进行rebase
git pull --rebase

#也可以做全局配置
git config --global pull.rebase true
git config --global branch.autoSetupRebase always

分支合并使用 no-ff

解决fast-forward 合并的路线图问题,这种 merge 的结果就是一条直线,无法明确看到切出一个新的 feature 分支,但是使用 no-ff就可以明显看出新feature分支的合并路线图
# 合并sprint01 到 develop 分支
git merge --no-ff feature/sprint01
 

© 天行者YANG 2020 - 2022