初识 Git 工作流程

(文中图片均来源于网络)

Git

Git已是代码版本管理的标配，其分布式、多分支功能让人印象深刻。

Git工作流程（Git Workflow）

当项目需要多人共同开发时，规范工作流程就变得越来越重要。合适的工作流程能让多人协同开发更加顺利和高效。

目前主流的Git工作流程有三种：

• Git Flow（版本发布）
• GitHub Flow（持续发布）
• GitLab Flow（持续发布、版本发布）

三种工作流程各有优缺点，对于不同类型的项目有各自的用武之地。笔者开发Android项目时使用的是Git Flow，对此比较熟悉。其余两种工作流程，笔者出于学习的目的，在文中谈谈自己的理解。

Git Flow

从分支分类开始，有以下几类：

长期分支、主要分支

• master（主分支）：稳定可发布、产品线
• develop（开发分支）：处于开发状态

git checkout -b develop master
git push origin develop
复制代码

短期分支、支持性分支

• feature（功能分支）
• release（发布分支）
• hotfix（修复分支）

feature 功能分支

git checkout -b feature-main develop
# git commit 1
# git commit 2
# git commit 3
git checkout develop
git merge --no-ff feature-main
git branch -d feature-main
git push origin develop
复制代码

--no-ff

release 发布分支

git checkout -b release-1.0 develop
# 可能在该阶段再分出 fix-* 分支来修复发布前的问题，会有git commit和 git merge 操作。
复制代码

发布分支已测试完毕，问题已修复，可发布时，将代码同步到master分支中。

git checkout master
git merge --no-ff release-1.0
git tag -a v1.0
git push origin master
git push origin v1.0
复制代码

若在发布分支中有修复问题，那么这些提交也要同步到develop分支中。

git checkout develop
git merge --no-ff release-1.0
git push origin develop
复制代码

删除发布分支。

git branch -d release-1.0
复制代码

hotfix 修复分支

当线上版本有紧急问题需要修复，develop分支还处于下一个版本的开发状态，不好从开发分支分出修复分支，选择从master分出hotfix-*分支来修复该紧急问题。

git checkout -b hotfix-1.2.1 master
git commit -a -m "Bumped version number to 1.2.1"
复制代码

该紧急问题被修复，并验收通过时发布修复版本，同步代码到master分支。

git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a v1.2.1
git push origin master
git push origin v1.2.1
复制代码

接着将代码同步到develop分支。

git checkout develop
git merge --no-ff hotfix-1.2.1
git push origin develop
复制代码

删除修复分支。

git branch -d hotfix-1.2.1
复制代码

实际操作中，会将master作为开发分支，因为它几乎是Git相关工具的默认分支，可以省去大量切换工作。新建诸如release、production分支作为产品分支。

GitHub Flow

只有一个长期分支master，很适合持续发布的项目，如：网站，相比Git Flow 更简单、易用。

git checkout -b bug47833 master
git commit
git checkout master
git merge --no-ff bug47833
git push origin master
复制代码

GitLab Flow

只有一个主分支master。该工作流程最大原则是“上游优先”，只有master分支的代码提交，才能应用到下游分支中。

在开发需求或修复问题时，可以使用GitHub Flow方式从master分支分出工作分支，开发完成后以合并请求合并到master分支，当验收通过时，就可以合入到下游分支并发布了。

持续发布

版本发布

结束语

本文主要介绍了3种Git工作流程，其中重点介绍了Git Flow。目前笔者所在的团队使用的工作流程类似于GitLab Flow，在这里只是简单的介绍，而GitHub Flow工作流程未真正实践过，出现在文中是为了丰富文章内容。

文中的Git工作流程并不是全部，完全可以自己按需扩展或全新定义出适合项目的工作流程。

参考资料

• Git 工作流程
• A successful Git branching model
• GitHub Flow
• Introduction to GitLab Flow