Git操作与git工作流
当我们谈论git时，我们首先会想到版本控制和各种命令及概念。git基础操作请看我的另外一篇文章【操作】git版本控制流入门命令FQ#1
我首先为【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的代码贡献说明
看看官方说明文档
github工作流程
iisues
iisues是提交建议，使用问题，软件bug入口的入口。如果我们想参与一些开源项目，最开始的时候可以从录入iisues，解决iisues开始。
如 https://github.com/apache/dubbo-admin/issues/421
官方说明文档
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工作流，有助于深化理解工作中具体的实际操作。
参考资料
https://github.com/oldratlee/translations/blob/master/git-workflows-and-tutorials/README.md
