一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，点击查看活动详情。
之前整理过一篇 Git使用实战：多人协同开发，紧急修复线上bug的Git操作指南。 得到大家积极的反馈。
今天在之前的基础上，结合这一年多来使用Git踩的坑，将我们总结的Git使用规范分享出来，供大家参考。
分支说明
master
- 主分支 , 最终在master分支对外发布
- 此分支只能从其他分支合并，不能再这个分支直接修改
- 另外所有在master分支的推送应该打标签做记录,方便追溯
- 例如release合并到master
develop
- 主测试分支 , 基于master分支创建
- 包含所有要发布到下一个版本的代码
- 只能从其他分支合并
- release 分支开发完成合并到develop
release
- 开发分支, 基于master分支创建
- 主要用于新需求新功能的开发
- 功能开发完毕后合到develop分支发布测试环境，测试通过后合并到master发布生产环境
- release可同时存在多个
hotfix
- 补丁分支 , 基于master分支创建
- 主要用于对线上的版本进行BUG修复
- 修复完毕后合并到develop分支发布测试环境，测试通过后合并到master发布生产环境
- 属于临时分支 , 补丁修复上线后可选删除
- 紧急修复线上bug的分支操作 可点击这里查看
使用流程
- 初始化项目 , 默认创建master分支
- 从master拉取第一个develop分支
- 从master拉取第一个release分支(多个开发人员拉取多个release同时进行并行开发 , 互不影响)
- release分支完成后 , 合并到develop
- 从develop分支打tag进行提测，提测过程中在原release分支修改BUG，重复步骤4
- 测试通过后合并release到master，基于master分支打tag发布生产环境.此时可删除当前release分支
- 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改
- hotfix通过测试上线后可选删除当前hostfix
使用习惯
- 多人开发过程中，每个人本地根据需求或者场景创建自己的分支，比如：release-wzy-3.3.0。 其中release是分支类型，wzy是用户名，3.3.0是当前分支对应的版本号
- 开发完毕后把release分支合并到develop分支，进行测试。注意千万不要把develop分支合并到自己的release分支。（因为不能把别人的代码拉取到自己本地，避免冲突，更要避免将别人没有测试通过的代码提交到master）
使用工具
我之前的习惯一直是使用命令，在同事的安利下开始使用goland集成的git管理工具，真香：
这里显示的就是当前文件对应的分支：
点击之后可以查看当前工程下所有的分支，可以方便的进行检出、合并。
最友好的是可以进行修改文件的对比，这样我们就不用使用git diff进行比较了。（工具化的比较比git diff的比较更加直观，而且更方便修改）
注意：当我们在一个窗口同时打开多个项目时，git工具是通过你选中的文件而不是你选中的项目目录确定的。
我的习惯是在需要操作Git时，选中该项目下的一个文件，先看最右下角的git分支名称，自查一下。然后在文件的任意位置右键，选择git，进行相关操作就可以了。
Goland是这样的，相信像webStrom、PHPStorm等jetbrains公司推出的开发工具都天然支持Git可视化操作。
TIPS
- 发布线上时一定是master合并开发分支，develop分支可能存在其它未测试通过代码
- 两个分支进行合并时一定要拉取一下最新代码
总结
Git非常强大且高效，这篇文章以及 Git使用实战：多人协同开发，紧急修复线上bug的Git操作指南。 都是基于我们的项目特点做的使用总结。
抛砖引玉，希望可以给大家一些帮助。
最后
感谢阅读，欢迎大家三连：点赞、收藏、投币（关注）！！！
