GIT 协同

Git 协同工作流选择

发布于 2021-08-26 09:32:54 浏览：1123 订阅该版

[tocm]

20 | Git协同工作流，你该怎么选？

与其花时间在 Git 协同工作流上，还不如把时间花在调整软件架构和自动化软件生产和运维流程上来，这才是真正简化协同工作流程的根本

# 1. 中心式协同工作流

- 本地操作

- pull

- commit

- push

- Git 操作

- 先把你本地提交的代码放到一边。

- 然后把服务器上的改动下载下来。

- 然后在本地把你之前的改动再重新一个一个地做 commit，直到全部成功。

![img](https://api2.mubu.com/v3/document_image/d00f13ef-f75e-4b9f-8309-579f4b05f685-6852969.jpg)

- 缺点
  - 代码干扰太严重

# 2. 功能分支协同工作流

- 创建一个新的功能分支

- 开发完成后提pr到master

- 目的

- 快速提交

- 快速合并

- 快速完成

![img](https://api2.mubu.com/v3/document_image/a30fe1ef-7cff-47b0-b9cf-6054f9daf792-6852969.jpg)

# 3. GitFlow 协同工作流

- 欲望不满足

管理好代码与环境的一致性。

- 希望有一个分支是非常干净的

- 希望当代码达到可以上线的状态时，依然可以开发下一个版本的代码

- 对于已经发布的代码，也会有一些 Bug-fix 的改动，不会将正在开发的代码提交到生产线上去

- GitFlow 协同工作流： Vincent Driessen 于 2010 年在 A successful Git branching model 这篇文章

- 整个代码库中一共有五种分支

- Master 分支，可发布

- Release 分支，发布的准备工作

- Developer 分支。是开发分支

- Feature 分支，功能分支，开发完成，向develop合并，自删

- Hotfix 分支，Bug-fix，完成后删除

![img](https://api2.mubu.com/v3/document_image/5d0c045e-f92b-4df8-b370-e24c03e5d318-6852969.jpg)

- 缺点
  - 太复杂了
  - 而且 develop 和 master 往往是相同的，但是要维护两个仓

# 4. GitHub Flow（推荐）

-  GitHub Flow = Forking flow

- 流程

需要CI/CD

- fork 到自己仓库

- 做开发

- 本地链接两个远程仓，自己和上游仓

- 本地起功能分支

- push 到自己仓库

- 提 pull request

- 合并

- 协同工作流的本质

- 不同的团队能够尽可能地并行开发。

- 不同软件版本和代码的一致性。

- 不同环境和代码的一致性。

- 代码总是会在稳定和不稳定间交替。我们希望生产线上的代码总是能对应到稳定的代码上来。
  
# 5. 附：如何为github上牛逼的开源项目贡献代码

1. fork需要协作项目
2. 克隆/关联fork的项目到本地
3. 新建分支（branch）并检出（checkout）新分支
4. 在新分支上完成代码开发
5. 开发完成后将你的代码合并到master分支
6. 添加原作者的仓库地址作为一个新的仓库地址
7. 合并原作者的master分支到你自己的master分支,用于和作者仓库代码同步
8. push你的本地仓库到GitHub
9. 在Github上提交 pull requests
10. 等待管理员（你需要贡献的开源项目管理员）处理