Git 工作流程
至目前为止,笔者使用过三种工作流
- Feature Branching 工作流
- Fork 工作流
- GitFlow 工作流
目前公司用的是Feature Branching。顾名思义,就是创建分支,在分支上开发需求,等开发好了,测试环境也用此分支来发布,测试通过。发预生产时,merge 到 master 分支上,再在预生产如此做。同理,发生产时也是如此
Feature Branching
特点
适合小团队,一两个人开发,多人协作就有问题
任何新的功能点(feature)通过新建分支(branch),再在分支上完成开发
工作流程
- 需求发布日期是20220526
- 以发布日期为分支建立:
git checkout -b 20220526
- 以发布日期为分支建立:
- 在20220526分支上开发需求,本地开发完后,推到远程分支
git push origin 20220526
(远程分支没有该分支为视为创建此分支)
- 测试-提bug-修复bug,都在 20220526 分支
- 测试完毕,需发布到预生产,上服务器
git checkout master
git merge 20220526
- 继续预生产测试,后续的生产如上操作
Fork 工作流
特点
开源项目多以此为流程,开发者提交 pr,主仓库管理员合并其代码
操作繁琐,每个人一个仓库,更适合十几个人以上项目
工作流程
开发者 fork 项目到自己的仓库
git clone
到自己的本地仓库并获取原项目(upstream)跟踪原项目代码情况
- 自己远程仓库一般别名为 origin,upstream(上游)意味主仓库
git remote add upstream git@...
在本地仓库上做开发,commit,push
同步主仓库代码
git pull upstream master
因为考虑到 commit 的整洁性,会使用 rebase 来合并 commit
- bash
git fetch upstream dev git rebase upstream/dev git commit git push origin develop //或者 git pull upstream develop --rebase
这里还要考虑的是合并修改(见下文)
通过 pull request(pr)提交到主仓库
合并修改
简单来说,就是远程仓库有代码更新,从而会导致我们提交的 Pull Request 时会导致冲突,因此我们可以在提交前获取到原仓库(upstream)最新的代码
切换到 master 分支
bashgit checkout master
以 master 分支为铆点拉去 upstream 远程分支最新的代码
bashgit pull upstream master
切换回 branch1(自己的开发分支)
bashgit checkout branch1
把 master 的 commit 合并到 branch1:
bashgit merge master // 或 git rebase master
把更新的代码提交到自己的远程仓库:
bashgit push origin branch1
PS:merge 和 rebase 的区别在于,merge 只是做合并提交作用, rebase 会整理分支,让分支更加清晰(rebase 让分支更加清晰优雅)
GitFlow流程
特点
- 分支各司其职,覆盖大部分开发场景
- 预期 master 分支中任何 commit 都时可部署的
- 严格按照流程执行,出现重大事故的情形会大大降低
缺点是
- 过于繁琐,无法要求所有团队成员按照这个流程严格执行
- 违反 git 提倡的 short-lived 分支原则
- master 分支历史记录并不干净,只能通过打 Tag 标记哪些是 master 真正要部署的
- 对持续部署和 monorepo 仓库不友好