【操作】git版本控制-相关工作流

git操作与git工作流

当我们谈论git时,我们首先会想到版本控制和各种命令及概念。git基础操作请看我的另外一篇文章【操作】git版本控制流入门命令FQ#1

我首先为【git操作】做一个定义即git命令相关的操作,比如创建分之,合并,提交,撤销等。

【git工作流】定义为基于git版本控制工具,通过但不限于git命令的正确使用,用于完成版本控制,软件交付的整个流程规范。

git工作流并不是指git相关的操作,当然git相关的操作是git工作流的基础,git工作流更多的是说明基于git仓库管理工具如何更好的开展软件开发工作的一整套流程和规范。

git基本操作

业界主流有三种工作流模式

一 Gitflow工作流

第一种是Gitflow工作流, Gitflow工作流是经典模型,处于核心位置。 以下是一个以gitflow作为工作流的约束范例,可以参考实践。

相关术语

master主干

主分支,产品的功能全部实现后,最终在master分支对外发布。用于生产环境发布的完整代码库版本。master主干长期存在,并与生产环境的版本保持一致。

develop分支

开发分支,基于master分支克隆,开发编码测试工作在此分支进行。主要使用git check -b 命令

Git版本控制,主要约定如下

开发人员以分支代码为基准进行开发,测试,并发布测试环境。以主干代码为基准进行灰度环境,生产环境上线部署。原则上,当前主干代码应该以当前线上运行的实际代码保持一致。

主干合并规则

用于经过测试同事验证通过的开发分支,开发人员收到测试邮件之后操作,将开发完成的工作合并到主干分支。主要使用git merge 命令

操作步骤

1 以当前主干为基准进行建立标签里程碑。标签标注以当前线上版本号命名。 2 整理代码,以分支代码为基准进行合并,更新主干代码库。

二 Forking工作流

Forking工作流是分布式github风格的,也叫做github工作流,强调项目fork 和pull request

我们看看go语言开源项目beego的代码贡献说明

beego贡献文档说明.png

看看官方说明文档

github工作流程

image.png

iisues

iisues是提交建议,使用问题,软件bug入口的入口。如果我们想参与一些开源项目,最开始的时候可以从录入iisues,解决iisues开始。

如 https://github.com/apache/dubbo-admin/issues/421

github-issues.png

图片来源参考文档-对iisues进行标签识别

官方说明文档 https://guides.github.com/features/issues/

三 Gitlab工作流

Gitlab flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支master,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。

参考官方文档 https://docs.gitlab.com/ee/workflow/gitlab_flow.html

在实际的开发团队中,三种工作流方式一般都会混合使用,根据团队特点,做一些整合。比如采用gitlab界面化系统管理代码,并结合gitflow工作流进行开发。

本文着重提出了业界主流的三种git工作流方式,以及每种工作流的主要特点,并没有细化到具体的使用场景和命令详情,给出了一些官方链接。如果按照武学小说来说,算是三种流派。感兴趣的读者,可以以工作流为主线,参考网上对应的文档学习与思考。从根本上认识三种git工作流,有助于深化理解工作中具体的实际操作。

原文发布于微信公众号 - 图南科技(tunan_technology)

原文发表时间:2019-07-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券