前端团队工作流

部分内容源于 玩转 Git 三剑客(极客时间) 笔记

分支管理策略

分支命名规范

• feature-版本号 (功能开发分支)
• fix-开发人员域名-bugID (修复分支)
• test (测试环境部署分支)
• uat(预发布环境部署分支)
• master(主干分支)

合并须知

• develop 分支及 uat 分支为环境部署分支，提 pr 由项目负责人 code review 通过后进行合并，通过 jenkins 检测代码变动实现自动发布

实行 code review 的具体步骤

1. master、 uat 分支设置为保护分支
2. 提测时开发分支发 pull requests 向 uat 合并(但不点通过)
3. QA 验收时，前端进行代码初步 review 及代码修改
4. QA 验收测试环境通过，前端将步骤二发起的 pull requests 点击通过 merge 到 uat 分支
5. uat 分支发布到预发布环境，uat 环境的 bug 修改，通过开发分支提 pull requests 的方
   式往 uat 进行合并
6. uat 验收通过，将需要发布的个人开发分支向 master 分支提 pull requests
7. master 分支打上 tag，用 tag 进行生产环境发布，如有线上 bug，基于 master 新建临更分支，重复步骤 1->6

通过 tag 进行发布，规避多人协作 master 分支有人改动而导致发布内容与版本不一致

tag 命名

发布 tag：版本号
临更 tag：hotfix-版本号

选择适合团队的分支工作流

• 团队人员组成：全资深/高级 or 各等级搭配
• 研发设计能力
• 输出的产品的特征：toB or toC
• 项目难易程度

1、主干开发

google, facebook 采用;

• 概念：任何人的 commit 会直接推送到 main 分支，以便其他成员第一时间看到变更。
• 适用于：
  • 组件开发团队，成员能力强且人员少
  • 需要快速迭代，想获得 CI CD 全部好处。且设置了一套产品特性快速切换机制的团队

2、Git FLow
一线互联网公司采用的不多见，比较繁琐。

3、GitHub FLow

• 分支集成时经过 code review 之后可以立即发布

4、GitLab FLow

基于 Github Flow 的拓展，在分支合并到主干分支之后，不使用 master 立即发布。而是拉一个 Production 分支去上线，不影响 master 的持续集成。

如何挑选合适的分支集成策略？

github 处仓库设置，挑选团队拟定的策略

• auto rebase ：将 feature 分支的 commit 逐一添加到主干分支，不改变原分支
• auto merge：新生成一个 merge commit 添加到主干分支
• auto squash：多个 commit 合并为一个 commit 添加到主干分支，不改变原分支

使用 issue 跟踪需求、bug

• Labels：自定义的分类集合

• MileStones：里程碑

创建 issue
可在 setting 中自定义各种 template，并最终作为.github 中的 md 文件被提交才会生效。

优点
团队交流便捷，可追溯记录，推荐使用 issue 来进行团队任务需求的跟踪。

如何用 project 管理 issue？

此处为一个较全模板范例，具有待办、进行中、完成等状态集。

团队如何实行 code review

• 设置 Branch Protection Rules，针对指定分支定义 review 规则

团队协作时如何做多分支集成？

场景：2 个开发分支，基于同一个 master 的点拉出开发，开发完成后想合并到 master

merge

• 分支之间合并时只需解决一次全冲突即可
• 会在 feature 分支上生成一个新的 merge commit

squash

• 将多个 commit 合并为一个 commit，线性加到 master 上
• 无冲突时：不会改变原 feature 分支

• 有冲突时：将 feature 分支往前新生成一个 commit

rebase
普通：
需要变基的每次 commit 都要解决一次冲突，也是很多人觉得 rebase 麻烦的原因。但可以让 master 保持线性

• 无冲突时：

• 有冲突时：

  • step1: 在特性分支执行 git rebase master
  • step2: 解决每一次冲突后 git add .
  • step3: 直到 git rebase –continue 时没有冲突解决后，将特性分支 push 到远程特性分支

• PR 到 master 之后

高级用法：
git rerere，帮助你缓存每次解决过的块冲突。在下次遇到的时候会自动读取缓存已解决过的冲突而无需再执行重复操作

• 前提配置 rerere：git config --global rerere.enabled true
• step1: A 要往 master 合并，A 先 git merge master
• step2: merge 解决冲突后，必须 add 并生成一个新 commit 在 A 分支，方便 rerere 寻找
• step3：A 分支回退到 merge 之前的 commit，这一步是为了避免出现不干净的 commit
• step4：A 分支执行 git rebase master，报 conflict，但此时不用我们自己再去手动解决冲突。呈现给我们的已经是解决完成态，只需 wq!退出后继续每次执行 git rebase –continue 即可