前言
- 最近工作中发现,很多开发人员连最基本的Git怎么使用都不知道,比如什么时候切分支,什么时候合并代码,代码遇到冲突怎么办,经常出现掉代码,代码合并后丢失的情况。
- 以下为个人总结的常规Git开发工作流程的使用,每个公司使用不一致,仅供参考。
分支分类
- dev(开发)
- test(测试)
- uat (预发布)
- master (生产)
研发流程
- 需求评审
- 开发排期
- 编码开发
- 冒烟测试(单元测试)
- 冒烟通过,提交测试,合并代码到测试分支,部署测试环境
- 测试环境测试,开发修 BUG
- 测试完成,提交预发,合并代码到预发分支,部署预发环境
- 预发环境测试,开发修 bug
- 测试完成,产品验收
- 验收完成后,基于生产分支进行TAG
- 提交生产,合并代码到生产分支,部署生产环境
- 生产运营(客户)验收
- 验收完成,结项
实际操作
代码拉取
git clone https://code.xxx.com/xxx/xxx.git
- 查看本地分支:
git branch
- 查看远程分支:
git branch -a
创建版本分支
- 本地创建版本分支:
git branch fix-20240223-order
- 本地切换版本分支:
git checkout fix-20240223-order
- 本地推送版本至远程仓库:
git push origin fix-20240223-order:fix-20240223-order
分支名称是有规范和含义的,不能乱取
推荐格式:分支责任-需求日期/需求号-业务类型,一般按部门规范来,常见的有以下几种:
- feat:新功能
- fix:修补bug
- doc:文档
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- test:测试
- chore:构建过程或辅助工具的变动
- 为啥拉取的是生产/预发分支
之所以要拉取 master 分支而不是拉取 dev/test,是因为后者可能包含着一些其他成员还未上线或者可能有 BUG的需求代码,这些代码没有通过验证,如果被你给拉取了,然后又基于此进行新的需求开发,那当你需求开发完成,而其他成员的需求还没上线,你将会把这些未验证的代码一起发送到 uat/master上,导致一系列问题。
需求完成,提交代码
- 提交代码:
- 首先先在本地把新的改动提交,提交描述的格式可以参考着分支名的格式
如果是新需求的提交,可以写成 “feat: 需求20240111-新增导出”
如果是 bug 修复,可以写成 “fix: 禅道3387-重复请求处理”
- 提交本地代码至远程仓库
git add .
git commit -m "提交描述"
git push origin fix-20240223-order:fix-20240223-order
- 提交之前可能需要更新,因为该分支是一个版本分支,可能开发人员有几个人同时在这个版本分支进行开发,这个时候可能同一种业务就可能存在代码冲突,需要解决。
版本需求完成,合并代码
- 首先,我们需要认知到的是,每一个分支应该只对应一个版本,例如当我们开发01版本时,那么就创建一个 feat-01-order 分支进行开发;开发版本 02 时,就另外创建一个 feat-02-member 分支进行开发;修改生产环境的某个 bug 时,就创建 fix-bug-3378 进行开发,等等。
这样做的目的是,能够把不同的功能/需求/修改分离开来。想象一下这样一个场景,如果有某些紧急的需求是需要提前上线的,而此时你的分支里既包含了这些紧急的需求,又包含了其他未开发好的需求,那么这两种需求就不能拆开来分别进行提测和上线了。
- 其次,在合并代码时,我们要将四种分支模型(dev、test、uat、master)作为参照物,而不是把关注点放在自己的分支上。比如我们要在 dev 上调试,那就需要把自己的分支合并到 dev 分支上;如果我们需要提测,则把自己的分支合并到 test 分支上,以此类推。
我们要关注到,这四个环境的分支上,会有什么内容,会新增什么内容。「切记不能反过来将除了 master 之外的三个分支合并到自己的代码上!!」 如果其他成员将自己的代码也提交到 dev 分支上,但是这个代码是没有通过验证的,此时你将 dev 往自己的分支上合,那之后的提测、上预发、生产则很大概率会出问题。「所以一定要保持自己的分支是干净的!」 而 master 分支对应的是生产环境,一般是最新的稳定版本,所以合并到自己的分支以获取最新的更改也是没什么问题的。
- 前面我们已经把本地的版本分支推送至远程仓库后,在本地进行分支合并至 dev或者test
- 把 本地版本分支 fix-20240223-order 更新至最新的代码,如合并至dev分支,更新dev分支至最新代码
- 切换至 dev 分支:
git checkout dev
- 版本分支合并至dev分支(冲突解决):
git merge fix-20240223-order
- 环境分支推送至远程仓库:
git push origin dev
常见问题
预发环境修完的 bug 要重新走测试再走预发,为什么呢?
预发布环境是介于测试和生产环境之间的一个环境,它的目的是模拟生产环境并进行更真实的测试。它是一个重要的测试环境,需要保持稳定和可靠。通过对修复的BUG再次提交到测试环境测试,可以确保预发布环境中的软件版本是经过验证的,并且没有明显的问题。
当然,也不是非要这么做不可,紧急情况下,也可以选择直接发到预生产重新测试
代码合并错误,并且已经推送到远程分支,如何解决?
- 假设是在本地合并,本来要把特性分支合并到 uat 分支,结果不小心合到了 master分支
- 切换到特性分支合并到的错误分支,比如是 master:
git checkout master
- 查看最近的合并信息(按 q 退出查看):
git log --merges
- 撤销合并:
git revert -m 1 <merge commit ID>
【这里的 merge commit ID 就是上一步查询出来的 ID 或者 ID 的前几个字符】 - 撤销远程仓库的推送:
git push -f origin master
【这个命令会强制推送本地撤销合并后的 release 分支到远程仓库,覆盖掉远程仓库上的内容。(即,得通过一个新的提交来“撤销”上一次的提交,本质上是覆盖)】
cherry-pick 指令
- 作用:选择某些提交的变更并将其应用到当前分支
- 与 merge 的区别:如果你需要另一个分支的所有代码变动。那么就采用 merge;如果你只需要部分代码变动(某几个提交),那么就采用 cherry-pick
场景:有时候分支不一定是完全按照需求号来开发的,可能按照周期来进行开发,那当前版本内的分支上,可能就会包含着很多需求的提交,这时候,如果产品要求你只上某一个需求,但是其他的暂时还不能上,那就需要使用到 cherry pick 的操作,将该需求囊括的所有提交应用到对应环境分支上。「一定要注意梳理清楚被拆分需求是由多少 commit 组成的,不要有遗漏和多选。」
【更多参考:https://www.ruanyifeng.com/blog/2020/04/git-cherry-pick.html】
写在最后
-
在团队内部使用规范的 Git 工作流程,可以帮助我们提高协作效率,减少混乱和冲突。比如规定好分支结构和命名规范,将使得代码库的分支结构更加清晰明了,更易于管理。反之,开发者可能会按照自己的喜好随意创建分支,导致代码库分支结构混乱。
-
除此之外还有很多好处,降低错误风险、增加代码可追溯性、简化发布流程、促进持续集成与持续交付等等。
-
参考资料:https://blog.csdn.net/u010800804/article/details/109594867