Skip to content

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 分支

    bash
    git checkout master
  • 以 master 分支为铆点拉去 upstream 远程分支最新的代码

    bash
    git pull upstream master
  • 切换回 branch1(自己的开发分支)

    bash
    git checkout branch1
  • 把 master 的 commit 合并到 branch1:

    bash
    git merge master
    //
    git rebase master
  • 把更新的代码提交到自己的远程仓库:

    bash
    git push origin branch1

PS:merge 和 rebase 的区别在于,merge 只是做合并提交作用, rebase 会整理分支,让分支更加清晰(rebase 让分支更加清晰优雅)

GitFlow流程

特点

  • 分支各司其职,覆盖大部分开发场景
  • 预期 master 分支中任何 commit 都时可部署的
  • 严格按照流程执行,出现重大事故的情形会大大降低

缺点是

  • 过于繁琐,无法要求所有团队成员按照这个流程严格执行
  • 违反 git 提倡的 short-lived 分支原则
  • master 分支历史记录并不干净,只能通过打 Tag 标记哪些是 master 真正要部署的
  • 对持续部署和 monorepo 仓库不友好

工作流程

640

参考资料