1 提交建议
- 提交代码前要先更新(svn up)，编译通过，功能测试正常。
- 保持原子性的提交，建议一个功能或一个bug提交一次，不建议一次提交多个功能或bug，也不建议一个功能或bug分多次提交。
- 提交代码的命令顺序：svn up，（svn add），svn diff，svn commit –m /-F。
- 提交代码备注明确。可以参照第3章的日志格式。
- 建议提交代码完成后，用另外一套代码更新刚才的提交，并编译，测试。
- 为方便提交svn代码时的提交日志的编写，可以参考如下两种方式：
方法1：
#cd /home/xxxxx（user name）
#vi ~/.subversion/config
#修改或添加editor-cmd = vi
Note：
设置后提交代码不需要加 -m 参数，会自动打开vi。写完comment之后，保存退出vi（wq），代码自动提交。
如果中途放弃这次提交，可以强制退出vi（!q），此次svn commit终止。
方法2：
svn commit --editor-cmd=vi file1.txt fil2.txt
2 日志格式
<type><module>:<summary> //空一行 Description: 问题的现象描述。 the phenomenon, lower case is recommended, especially the first character. Reason: 问题的根本原因。 the reason Solution: 问题的解决方案。 the solution Code Review: 帮忙检查代码的人员名单， 如果没有进行code review需注明为”no review”。 RD1,RD2,RD3,…/ no review Test Result: 问题的测试情况，测试通过用pass， 未测试需要注明没有测试的原因。 pass/no test for environment
2.1 type和summary说明
type代表某次提交的类型, 比如是修复一个bug(问题)还是增加一个feature(功能)。summary是某次提交的简要说明，type值只能是如下表格中列举的值。所有的type类型及对应的summary内容如下。
|
type |
commend |
summary |
|
fix |
修复bug |
bug编号如alpha bug 56；如果没有编号，简要说明下该bug的来源，比如是由谁发现的discovered by RD XXX |
|
feature |
新增功能 |
如果是参考了其他项目组的，可以注明组名和项目名；另外写明需求来源 |
|
porting |
同步相同项目组内不同产品的代码 |
porting的项目名和版本号 |
|
append |
追加提交，用于上次提交有遗漏的情况 |
上次提交有遗漏的版本号 |
|
patch |
同步三方如econet的patch |
注明该patch的来源 |
|
revert |
回滚到上一个版本 |
上一个版本的版本号 |
|
compile |
与项目构建工具、编译有关的问题 |
待补充 |
|
refactor |
代码重构，没有加新功能或者修复bug |
待补充 |
|
perf |
优化相关，比如提升性能、体验等 |
待补充 |
|
style |
仅仅修改了空格、格式缩进等，不改变代码逻辑 |
待补充 |
|
docs |
仅仅修改了文档 |
待补充 |
2.2 module说明
module代表此次提交涉及的模块类别，多个模块用逗号隔开。模块名只能是如下表格所列举的，请注意大小写。另外如果发现列表有遗漏的请提出。目前所有的module列举如下。
|
No |
Name |
Note |
No |
Name |
Note |
No |
Name |
Note |
|
1 |
busybox |
|
3 |
webserver |
|
5 |
samba |
|
|
2 |
dhcp |
|
4 |
webpage |
6 |
dlna |
|
|
|
. |
… |
|
. |
… |
. |
… |
|