🧐

ixugo

走出舒适区

Git

Git 工作流

工作流

有 4 种常用工作流

集中式
功能分支
Git Flow
Forking

集中式

本地修改后直接提交到远程 master，有冲突解决冲突。

团队不建议使用，代码混乱，容易出问题。

功能分支

功能分支工作流基于集中式工作流演进而来。适合开发团队相对固定，规模较小的项目。

开发新功能时，基于 master 分支创建一个临时功能分支，在分支上开发，开发完成后合并到 master。

仅在最后一步合并到 master 分支，使提交历史更简洁
不同的功能分配给不同的开发人员，避免冲突

具体流程

基于 master 创建功能分支
1

git checkout -b feature/xxx

在分支开发，推送到远程

1
2
3


git add xxx.go
git commit -m "add xxx"
git push origin feature/xxx

创建 PR
代码管理员对代码做 Code Review，审查完成合并到 master

merge 有三种方法

Create a merge commit，git merge --no-ff，所有 commit 合并成一个，添加到 master。该命令是指强行关闭 fast-forward，但会保存特性分支历史，推荐这种。
Squash and merge，git merge --squash，将不必要的分支上其 commit 压缩合并，创建一个新的提交添加到 master。
Rebase and merge，git rebase，将分支所有 commit 依次添加到 master，属于 fast_forward方式合并。

Git Flow

Git Flow 工作流是一个非常成熟的方案，也是非开源项目中最常用到的工作流。适合大型的项目或者迭代速度快的项目。

5 种分支

分支名	描述
master	发布状态，禁止开发，每次合并 hotfix/release 要打版本标签
develop	最新代码，禁止开发
feature	研发功能分支，基于 develop，开发完成后合并到 develop 并删除该分支
release	预发布分支，基于 develop，通过测试后合并到 master 和 develop，并删除该分支
hotfix	维护阶段分支，紧急 bug 修复，基于 master 分支创建，完成后合并到 master 和 develop 并删除

Forking

开源项目中，最常用到的是 Forking 工作流。

假设开发者 A 拥有一个远程仓库，如果开发者 B 也想参与 A 项目的开发，B 可以 fork 一份 A 的远程仓库到自己的 GitHub 账号下，在自己的仓库中修改，完成后向 A 的仓库提交 PR。

具体流程

fork 仓库

克隆仓库

1
2
3
4
5


git clone https://github.com/xxx/kitx
cd kitx
git remote add upstream https://github.com/ixugo/kitx
# 禁止推送到 upstream ，实际上一般也没有权限，因为那并不是你的仓库
git remote set-url --push upstream no_pus

创建功能分支

1
2
3
4
5


# 要同步 master 最新状态
git fetch upstream
git checkout master && git rebase upstream/master
# 创建分支
git checkout -b feature/files

完成开发，提交

1
2
3
4
5
6
7


# 在特性分支，同步远程仓库最新状态
git fetch upstream && git rebase upstream/master
# 提交代码
git add file.go
git commit -m "xxx 功能"
# 推送到自己的远程仓库
git push origin feature/files

在 github 自己的仓库那，创建 Pull request。

参考

Go 语言项目开发实战

A successful Git branching model

Git、GitHub、GitLab Flow，傻傻分不清？一图看懂各种分支管理模型

Git flow 开发指南

gitflow 是什么，有哪些优缺点？

Github 官方文档 pull requests 流程