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
- ```
git fetch upstream dev
git rebase upstream/dev
git commit
git push origin develop
//或者
git pull upstream develop --rebase
```
  1
  2
  3
  4
  5
  6
- 这里还要考虑的是合并修改（见下文）
通过 pull request（pr）提交到主仓库

合并修改

简单来说，就是远程仓库有代码更新，从而会导致我们提交的 Pull Request 时会导致冲突，因此我们可以在提交前获取到原仓库（upstream）最新的代码

切换到 master 分支
```
git checkout master
```
1
以 master 分支为铆点拉去 upstream 远程分支最新的代码
```
git pull upstream master
```
1
切换回 branch1（自己的开发分支）
```
git checkout branch1
```
1

把 master 的 commit 合并到 branch1：

git merge master
// 或
git rebase master

把更新的代码提交到自己的远程仓库：
```
git push origin branch1
```
1

PS：merge 和 rebase 的区别在于，merge 只是做合并提交作用， rebase 会整理分支，让分支更加清晰（rebase 让分支更加清晰优雅）

GitFlow流程

特点

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

缺点是

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

工作流程

640

# Git 工作流程

# Feature Branching

# 特点

# 工作流程

# Fork 工作流

# 特点

# 工作流程

# 合并修改

# GitFlow流程

# 特点

# 工作流程

# 参考资料

Git 工作流程

Feature Branching

特点

工作流程

Fork 工作流

特点

工作流程

合并修改

GitFlow流程

特点

工作流程

参考资料