团队开发分支命名策略
-
master：
主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。 -
develop：
开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。
其它分支为短期分支，其完成功能开发之后需要删除 -
feature/*：
特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。 -
bugfix/*：
bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。 -
release/*：
发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。 -
hotfix/*：
紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。
团队开发流程
集中式工作流
风格与SVN一致，工作流以中央仓库作为项目所有修改的单点实体。
查看集中式工作流详情
功能分支工作流
功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。
查看功能分支工作流详情
-
Gitflow工作流
Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。
查看详情 -
Fork工作流
Forking工作流是分布式工作流，充分利用了Git在分支和克隆上的优势。
查看详情
注释规范（Git Commit Guidelines。）
<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>
上面是一次Commit后Message格式规范，分成标题，内容详情，结尾三个部分，各有各的用处，没有多余项。
头部即首行，是可以直接在页面中预览的部分，入上面图中所示，一共有三个部分
- Type
- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
- Scope
用来说明本次Commit影响的范围，即简要说明修改会涉及的部分。这个本来是选填项，但从AngularJS实际项目中可以看出基本上也成了必填项了。 - Subject
用来简要描述本次改动，概述就好了，因为后面还会在Body里给出具体信息。并且最好遵循下面三条:- 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
- 首字母不要大写
- 结尾不用句号(.)
- Body 里的内容是对上面subject 里内容的展开，在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。
- Footer
footer里的主要放置不兼容变更和Issue关闭的信息。
总结
- 所有的新功能开发，bug修复（非紧急）都要从develop分支拉取新的分支进行开发，开发完成自测没有问题再合并到develop分支
- release分支发布到测试环境，由开发人员创建release分支（需要测试人员提出需求）并发布到测试环境，如果测试过程中发现bug，需要开发人员track到该release分支修复bug，上线前需要测试人员提交merge request到master分支，准备上线，同时需要合并回develop分支。
- 只有紧急情况下才允许从master上拉取hotfix分支，hotfix分支需要最终同时合并到develop和master分支（共两次merge操作）
- 除了master和develop分支，其它分支在开发完成后都要删除