开发规范

Github Issue

非终结性的commit提交时，message后要带issue号，格式为 #123
终结性的commit提交时，message前直接带上功能性标记，bug修正使用fixed，功能开发重构等使用close，例如：fixed #123或者close #123

每次发版本时，将根据issue记录编写changelog

例如: issue标题为用户管理，则此issue的粒度就过粗，可以分解为: 用户注册、用户登录、用户登录后看到的后台等等

由saberma对所有功能变动、Bug修正进行控制，并进行统一分配

手动测试功能正确的不算，只有被测试覆盖的代码才能称得上代码，以保证后来者的改动破坏到现有功能时能被及时提醒

测试用例分集成测试、单元测试；判断是否需要集成测试的标准是:只要是用户能够进行的操作都要有相应的集成测试；只要是内部使用的方法都要有相应的单元测试

由@saberma对每个关闭的issue进行检查，对于发生以下情况的issue要reopen

发现问题后不要直接处理，要先提交issue，以便日后跟踪；并在测试用例注释上相应的issue号，格式为 # issues#123

对于无法修正的，要将issue转至@saberma确认

版本发布后，尽量减少Gem更新的频率，以减少这些变动因素对系统稳定性的影响