项目采用(缩短周期的)敏捷开发模式，依赖于pull-request-review机制实现，大致贡献流程如下：
- 快速构建起一个可运行的空框架
- 分为三个组同时对三个app(功能模块进行开发)，功能需求都组内自己提出，自己实现．
- 每天进行多次Intergration(集成)，由各组的分支向master分支提PR，review时对无法修复的更新直接回滚．
- 每天晚上进行一次release(发布)，review后由master分支merge到stable分支．
组长主要负责代码仓库下某一分支(以下称为B)的开发与维护，操作流程为：
- 提出功能需求，并在组内协作实现该需求．
- 将组内代码
git commit,git push到B分支. - 确认某一功能需求已实现后，发起一个从
B分支到Master分支的PR - 在Code-reviewer通知整个项目已顺利完成一次Intergration后，发起一个从
Master分支到B分支的PR,并直接选择Ｍerage,接下来将最新版本的代码分发给所有小组成员 - 每天早上(即一次release后)，重复步骤4．
注意：
- 组长对分支
B负责，但应避免向Master或其他组的分支做任何写操作，不应向Stable分支做任何写操作 - 由于Intergration会消耗一定时间，在该时间段组内的commit可能会在步骤4中产生conflict,参考解决方法：
- 在Intergration期间不要开发，休息一会儿~~~
- 手动解决conflict：Discard不必要的项目更改(i.e:
db.sqlite3),然后在conflict处进行手动调整．
- 参考组员注意事项
组员主要参与代码仓库下某一分支(以下称为B)的开发，由组内协调开发方式
注意：
- 组员不应向
Master或其他组的分支做任何写操作，不应向Stable分支做任何写操作 - 提交commit时，应关闭
python manage.py runserver所创建的进程 - 提交commit或PR时，应注明代码内容或实现的功能．如果该功能完全解决某个issue,请在commit message或PR message中tag这个issue，并关闭issue．如果只能部分修复某个issue，请在issue下指出你已完成的工作．
- 提交commit时，不应全部提交，需要确认
db.sqlite3,*.pyc,001*.py等文件保持ignore - 从master(或其他任何分支)下载好最新代码后，应运行
python manage.py makemigrations
python manage.py migrate
python manage.py runserver以部署生产环境和测试运行
- 若部署生产环境时显示数据库中有table缺失，请使用
python manage.py migrate --run-syncdb来更新数据库