初识 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