GitFlow工作流常用操作流程。本文将讲解Git协作开发的流程。首发于glxe.top
现在的程序开发中，我想大家想不用github类的版本控制工具都很难了吧，也很难想象不用版本控制工具是怎么样的一个体验。但是Git会用还不行，Git的出现本意就是为团队协作的，git add, git commit, git push, 我想明白人看看就会了。如果在一个团队中开发代码，许多人共用一个分支，那也是不可想象的，冲突肯定是会随时发生的，不是你写的代码那冲突就会更加的麻烦。那git-flow 是一个 git 扩展集，接下来我跟大家分享下我和我的团队小伙伴的协作开发工作流程，那我这边呢其实没用到这个扩展，只是在git中使用了这些思想及流程。
其实Gitflow流程仍然使用一个中央代码仓库，它是所有开发者的信息交流中心。跟其他的工作流程一样，开发者在本地完成开发，然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。
索引
1.主要分支介绍
主要有这几类分支：
蓝色圆点就是源码主线master分支，方形的是版本标签（tag）
紫色圆点是develop分支，开发主线分支
橙色圆点是feature分支，新功能开发分支
绿色圆点是release，新版本发布分支
红色圆点是hotfix，bug修复分支
1. 1 master
源码主分支，记录版本发布的轨迹，也可以叫online，名字随便起，适合自己，开心就好，产品功能全部实现以后，此分支将会对外发布，即生产环境中需要部署的分支。通常此分支也是禁止直接取开发修改代码等动作。
1. 2 develop
开发分支，也是测试分支，这个分支是基于master分支的子分支，其他开发分支开发完了合并到此分支就可以进行测试了。其实这个master和develop两个分支都是作为主线分支，其他的分支都是临时分支，都是有生命周期的。也都是围绕两个主线分支开展工作的。
1. 3 release
发布分支，基于develop分支克隆，所有开发完成，或者是满足发布条件（或者deadline），此版本就需要合并到master分支和develop上，另外还需要打上版本标签。
1.4 feature
就是功能开发分支，也可以每个人建立一个以自己名字的分支，共同开发大版本的，每个人在自己的分支完成自己负责的功能模块即可。或者需要开发独立的功能点的，则必须要建立一个单独的分支来开发。当前分支做完后合并到develop分支上，自己的分支可以保留，继续下个版本，然后其他功能点分支就可以干掉了，开发完了一定要往父分支develop上合并，而且这个分支是不能和master产生关系，否则就破坏规则了。
1.5 bugfix
此分支也可以说是维护分支吧，通常在发布版本之间，测试没有测试到位，产生了意想不到的新bug，用来修复生产环境的紧急状况。这个分支是基于master分支的，也是生产环境中唯一一个直接从master分支派生出来的活动分支。快速修复问题后应该合并到master分支，并将develop
拉取更新。
命名约定
其实命名这块笔者公司是有自己的规则的。在这里呢按照上文的标准来吧。
主分支：master
主开发分支：develop
标签名称：v.xxx.release,其中xxx号为版本号，这个就根据自己的来定就可以了。如v.1.0.0.release
新功能开发分支：feature-xxx，其中xxx为功能点的简述。如feature-video-play
发布版本分支：release-xxx，xxx为版本号。如release-2.0.3
master修复分支：bugfix-xxx，xxx为简述。bugfix-video
sed -i 's/\"hostname\"\:.*$/\"hostname\"\: \"'$IPADDR'\"\,/g' open-falcon/agent/config/cfg.json
——未完待续，接下来将会分享流程中的命令使用