版本管理规范
版本管理规范
分支规范
主要分为4个分支，dev，test，master, release
dev用于本地开发
test用于发布测试环境
master 主线代码库
release分支，代表发布的线上版本
分支使用规范
开发人员在dev分支上开发，开发完成需要发布到测试环境的时候，合并代码到test分支，然后将test分支代码发布到测试环境，测试环境测试出来的bug，直接在test分支修改，当测试环境全部测试通过，准备发布到正式环境的时候，将test代码合并到master分支和dev分支，并且创建一个release分支并打tag，
分支名称为release_V版本号_yyyyMMddHHmmss
下一次迭代开发内容接着在dev分支上开发
当线上环境出现bug，需要修复的时候，直接在release分支修改发布测试环境，测试通过之后发布正式环境，然后将代码合并到dev分支
注意事项
- 在测试环境没有测试通过之前，禁止发布版本到正式环境，正式版本发布前半小时，必须邮件通知所有相关人员
- 每次提交代码，必须详细编写comment，
格式为 type：主题，如果为修改bug，必须标注对应的JIRA编号
type用于说明 commit 的类别，只允许使用下面8个标识。
- feat：新功能（feature）。
- fix：修补bug。
- docs：文档更新（documentation），包括代码注释的修改等。
- style： 格式，不影响代码含义的变更，如空格、格式化、漏掉分号等。
- refactor：重构，并未修复缺陷或添加功能。
- perf:：性能（performance）优化。
- test：补充测试用例。
- chore：构建过程或辅助工具的变动，例如文档生成工具、添加日志等
主题必须能清晰的表述这次提交代码的变动
- 控制提交粒度，不要一次性提交包括多个问题的代码，一个问题的相关代码作为一次提交
- 版本号规范，V主版本号.子版本号.修正版本号
主版本号.子版本号由产品经理确定，修正版本号从0开始计算，每次修改bug或者增加小功能时+1
分支使用流程图
Git 日常操作规范
1 推送本地分支代码到服务器（通过fetch+rebase）
推送本地代码到服务器时，需要先将服务器最新代码同步到本地，然后进行合并，再进行push操作。
在push之前，可有两种操作方式：git pull和 git fetch + git rebase。
建议使用 git fetch + git rebase两步操作。
在实际使用中，git fetch更安全一些。因为在merge前，我们可以查看更新情况，然后再决定是否合并。
而使用git rebase后产生的结果会比使用git merge更为简洁。
git pull：相当于是从远程获取最新版本并merge到本地。合并结果将会应用到本地分支。
git fetch：相当于是从远程获取最新版本到本地，不会自动merge。本地分支代码不变，需要继续进行merge或rebase。
git pull相当于 git fetch + git merge。
git merge：将两个分支进行合并，合并的结果是生成一个新的快照（并提交）。
git rebase：将两个分支进行合并，合并结果比较整洁，不会生产新的快照。
如下所示，假设当前工作分支为mywork，有人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了，它们之间"分叉"了：
以下是git merge后的结果：
以下是git rebase后的结果：
即：
$ git checkout develop
$ git fetch
$ git rebase
$ git push
Icon
可通过以下命令进行全局设置：
$ git config --global pull.rebase true
以后用git pull就等于git fetch+git rebase了
2合并服务器上的某个分支到另外一个分支（通过merge）
rebase原则：只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作。
为防止产生不可预料的事情，已经推送到服务器的分支直接经过merge合并，不使用rebase。