dev_guide

项目维护方案

版本管理
日志提交

1. 代码库调整

目前日常维护3个代码：

collie-common基础库
project-collie数据处理工具
project-collie-app数据应用

依赖关系如下：

project-collie - - - - - -> collie-common(python env-lib)
      ∧                      ∧
      ¦                      ¦
project-collie-app - - - - - ¦

问题： collie-common更新后，对运行时环境全局影响，在运行的历史项目可能会出现异常

方案：

将collie-common中与project-collie依赖紧密的部分代码合并

project-collie(包含collie-common部分源码)
			∧
			¦
project-collie-app

collie-common作为基础工具包，独立维护

2. 版本管理

需求场景：

能支持日常迭代开发、紧急线上bug修复、多功能并行开发
满足团队平日小周期的项目迭代
能够通过tag重建整个系统
支持code review
上线的代码是经过测试保证的，且能同步到下一次的迭代中

基本原则：

精确提交每次提交都是一个小而完整的功能或者一个BUG的修复。不应该出现多个功能点一块提交或者多个BUG一起修复的情况。如果一旦发现提交的代码有问题，可以方便的会滚到改动之前的正确状态，不会影响到其他协作者开发进程。
频繁的提交尽可能频繁的提交你的改动到远程仓库，这样，可以避免将来合并代码的时候产生大量的冲突以至于难以解决。同时，也可以让其他同事比较快的共享你的改动。
不提交不完整的功能如果你正在开发的新功能比较庞大，那么可以将这个功能尽可能拆分为几个逻辑模块，并且要保证分次提交的逻辑模块不会影响到整个系统的正确性。如果你只是因为临时的一些事情需要切到别的分支或者是临时需要中断开发（比如说下班）,那么应该使用Stash储藏功能来保存你的更改。
提交前进行测试不要想当然的认为自己的代码是正确的，提交之前应该经过充分的测试才能提交，即使是提交到本地仓库，也应该进行测试，因为这些代码在未来会被推送到远程共享给你的同事。
高质量的commit message 每次提交都应该包含完整的注释。团队成员应当遵循统一的提交规则，一般应当明确的体现出提交的类型以及具体的事情。

流程规范

结合我们日常实际开发场景，规定开发活动的分支：

master 分支：该分支上代码可以随时部署到生产环境
develop分支：作为每日构建的集成分支，达到稳定状态时，可以发布并merge回master
bugfix分支：用于快速修复，在修复完后merge回master

开发流程，举例说明：

日常开发进行中，开发人员在 dev_20201110_0 分支上进行 commit、push 代码，并解决掉日常协同开发中的冲突等问题，等到达到提测条件的时候，提测者，首先 merge master 分支上的最新代码 git merge --no-ff origin/master，使得 master 分支上的变更更新到迭代开发分支dev_20201110_0上面，之后，在 Gitlab 上面发起 Merge Request 请求，并指定合并人，同时也是Code Review 人，请求的分支选择master
被指定 Code Review 的人，对发起者的代码 Review 后，决定是否可以提交测试，若有问题，评论注释代码后，提交者对代码进行进行修改，重复步骤1，直到代码 Review 者认为 Ok。
步骤1-2重复多次后，就会达到一个稳定可发布的版本，即上线版本，上线前，在 Master 分支上面打 Tag。至此，一次完整的迭代开发完成。
若此次上线后，不久发现生产环境有 Bug 需要修复，则从 Tag 处新开分支bugfix_20201117、dev_bugfix_20150731 ，开发人员从 dev_bugfix_20150731分支上进行开发，提测code review在 release_bugfix_20150731 分支上，具体步骤参考2-3，测试环境验证通过后，发布到线上，验证OK，合并到 Master 分支，并打 Tag0.2.3，此次 Bug 修复完毕，专为解 Bug 而生的这两个分支可以退伍了，删除release_bugfix_20150731、dev_bugfix_20150731两分支即可

3. 日志提交

git commit message 提交规范

格式：

type: description

( 1 ) type（必须） : commit 的类别，只允许使用下面几个标识：

fix: 修复缺陷bug
add: 新功能、新特性
update: 更新代码、文档、配置等非完整性的局部调整
refactor : 重构已有功能，性能优化
test : 测试
release: 发布

( 2 ) description 是对本次提交的简短描述,

不超过50个字符
推荐以动词开头，如：设置、修改、增加、删减、撤销等