Git 提交准则
除了源码相关的东西之外，其他build产生的东西（如：maven的target文件夹，.idea文件夹等），均不能提交进入源码仓库，添加到.gitignore文件中忽略掉。
撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。
要严格按照我们指定的流程切换到指定分支，开发相应的功能。
Git fLow
在多组员，多项目等环境进行协同工作时，如果没有统一规范、统一流程，则会导致额外的工作量，甚至会做无用功。所以要减少版本冲突，减轻不必要的工作，就需要规范化的工作流程。Git Flow 是前人经过探索总结出来的一套Git分支管理规范和流程。
分支介绍
master 分支
master 分支上保存生成环境发布版本的代码，这个分支不进行commit修改，只能从其它分支合并，并且每次合并都打上发布的版本号，如上图所示，v0.1是项目初始化
develop 分支
develop 分支从master新建的一个分支，是我们的主开发分支，本分支包含下一个要发布的版本的所有代码。这个分支一般也不进行commit修改，主要从feature分支合并。
feature 分支
feature分支都是从develop分支新建，主要用来开发新功能，每个功能新开一个feature，保证功能的独立性。
release 分支
release 分支是用来打包测试使用，当要发布的功能都从相应的feature分支合并到develop分支上后，从develop分支新建release分支，如果测试过程中发现bug，在本分支上修复，确定后打包发布，同时合并到develop和master，打上标签保存。release 就可以删掉了，也可以选择不删掉此分支。
hotfix 分支
hotfix是用来修复上线版本BUG使用，从master分支新建，如上图，从v0.1新建了一个hotfix，修复后合并到master和develop，并且打上相应标签。
Git flow 流程
了解了每个分支的作用和从哪个分支新建而来之后，我们就可以仔细说说上图的整个流程了，这个流程我们先忽略hotfix分支，hotfix流程可以看上面hotfix分支介绍的内容。为了便于说明，我加入了一些标识给每个commit点。
1. 在master分支上初始化项目，加入.gitignore，产生master(1)
2. 从master(1)新建develop分支，产生develop(1)
3. 从develop(1)新建feature2分支
4. 从develop(2)新建feature1分支
5. feature1分支是第一个版本要开发的功能，在feature1(2)开发完毕，这个时候需要合并到develop分支，进入release阶段，合并后产生develop(4)，这个时候就可以吧feature1分支删掉了
6. 从develop(4)新建release分支，产生release(1)，打包后给测试人员测试，然后修复测试出的bug，修复commit后产生release(2)
7. 把release(2)打包发布1.0版本后，保存1.0版本到master，保证后面需要修复线上bug能快速找到源码。合并到develop分支，产生develop(5)，合并到develop是为了保证下一个release版本包含release(2)那些代码。分别合并后，可以选择是否删掉release分支，如果不删，也不能再在此分支上进行后续开发，后续开发只能新建分支来完成
8. 到此，一个完整的开发到发布的流程已完成，你可以继续下一个版本的开发，从develop(5)新建一个feature3分支
线上bug修复流程
当用户反馈系统有bug时，为了处理bug，需要从master中创建出保养分支；等到bug修复完成，需要合并回master。
1. 创建hotfix分支
2. 修改bug
3. 完成修复，合并到master发布
4. 打标签
5. 合并到develop
关于版本号
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改
- 次版本号：当你做了向下兼容的功能性新增
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。
标准的版本号必须采用 XYZ 的格式，其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
每次打标签后，建议将版本变更信息补充到项目wiki中。