Lucent's Blog

当时明月在,曾照彩云归。



代码在写我

Bug在De我

螃蟹在剥我的壳

漫天的我落在雪花上

而你在想我...

6ams5piO5pyI

Git工作流指南:GitFlow工作流

准备工作

在一切开始前,需要先配置SSH Key才能正常拉取或提交代码,方法如下:

  1. 在Git Bash或cmd中执行命令
ssh-keygen -t rsa -b 2048 -C "你的邮箱"
  1. 执行完成后会在你选择的路径下生成文件(id_rsa.pub即是你需要的)
    企业微信截图_16067009893653.png

  2. 将上面文件中的内容复制到如下图所示的输入框即可
    企业微信截图_16067012812030.png

工作流程

Git有许多工作流可供选择,其中包括:Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。
但请记住:这些流程仅应被视作为指导方针,而非“铁律”。因此,如果有必要的话,你可以组合使用不同的流程。

相对于传统的单分支或功能分支,Gitflow工作流定义了一个围绕项目发布的严格分支模型。

工作方式

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样,开发者在本地工作并push分支到要中央仓库中。

下面将逐个说明Gitflow工作流中的各个分支

历史分支

相对于单分支模式使用单一的master分支来记录历史,Gitflow工作流使用两个分支来记录历史(即master和develop)
master分支存储了正式发布的历史
develop分支存储了功能开发的历史

gitworkflowreleasecycle1historical.png

功能分支

每一个新功能都使用一个功能分支进行开发,这个功能分支应该从develop分支检出,而非master分支,master分支只保存生产环境代码

git checkout -b feature-test develop ##从develop分支检出新的功能分支

gitworkflowreleasecycle2feature.png

在此分支功能开发中:

# 查看本地代码状态
git status
# 拉取更新
git pull
# 提交代码到本地仓库
git add . ##'.'代表提交所有变化的文件,当然也可以指定文件
git commit -m '修改了***'
# 提交代码到中央仓库
git push

当功能开发完成后,需要将代码提交至develop分支,不能直接提交回master分支

# 拉取更新
git pull origin develop
# 切换到develop分支
git checkout develop
# 合并分支
git merge --no-ff feature-test
# 推送到中央仓库
git push
# 开发完成并合并成功后这个功能分支可以删除了
git branch -d feature-test

发布分支

当有功能需要发布的时候,可以从develop分支fork一个发布分支。这个分支用于开始发布循环,从这个时间点起,发布分支不再增加功能,只进行bug修复、文档和其他工作。当发布工作完成时,发布分支合并到master并打好tag。当然,从创建发布分支到发布完成所作的修改也要合并回develop分支。

# 从develop分支检出发布分支
git checkout -b release-v0.1 develop
# 推送分支到远程仓库
git push

当功能bug修复并发布完成,合并发布分支到master

# 切换到maste分支
git checkout master
# 将发布分支与当前分支合并
git merge --on-off release-v0.1
# 将合并后的内容推送到远程仓库
git push

由于发布分支对代码进行了bug修复,还需要将这些更改合并回develop分支

# 切换到develop分支
git checkout develop
# 将发布分支与当前分支合并
git merge --on-off release-v0.1
# 将合并后的内容推送到远程仓库
git push
# 此时,这个发布分支可以删除了
git branch -d release-v0.1

发布分支是作为功能开发(develop分支)和对外发布(master分支)间的缓冲。只要有合并到master分支,就应该打好Tag以方便跟踪。

# 创建Tag
git tag -a v0.1 -m 'release v0.1' master
# 推送Tag到远程仓库
git push --tags

维护分支

维护分支或说是热修复(hotfix)分支用于生成快速给产品发布版本(production releases)打补丁,这是唯一可以直接从master分支fork出来的分支。修复完成,修改应该马上合并回master分支和develop分支,master分支应该用新的版本号打好Tag。
gitworkflowreleasecycle4maintenance.png

当用户反馈系统有bug时,为了处理bug,需要从master中创建出维护分支hotfix,等到bug修复完成,需要合并回master

# 基于master新建hotfix分支
git checkout -b hotfix-v0.1.0.1 master

当问题修复完成,并测试通过后,将hotfix分支合并到master分支和develop分支,并打一个标签。

将hotfix分支合并到master分支:

# 切换回master分支
git checkout master
# 将维护分支与当前分支合并
git merge --on-off hotfix-v0.1.0.1
# 将合并后的内容推送至远程仓库
git push

将hotfix分支合并到develop分支,合并完成后删除hotfix分支:

# 切换到develop分支
git checkout develop
# 将维护分支与当前分支合并
git merge --on-off hotfix/v0.1.1
# 将合并后的内容推送至远程仓库
git push
# 至此,该维护分支可以删除了
git branch -d hotfix-v0.1.1

打上Tag:

# 创建tag
git tag -a v0.1.1 -m '修复了***' master
# 推送至远程仓库 
git push --tags

到此,Gitflow工作流的流程基本解释完了,但还是需要说明一下,任何工作流都只是参考,实际生产中还需根据实际情况灵活应用。

最近的文章

[0.62] The old good Dayz

Eventhoughdayz1.0hasbeenreleasedformanyyears,istillrememberthoseoldgooddaysinearlyaccesslike0.62,0.60,0.59,0.54...…

继续阅读
更早的文章

java8如何排序Map

在Java中,有多种方法可以对Map进行排序,但是我们将重点介绍Java8Stream,这是实现目标的一种非常优雅的方法。…

继续阅读