近段时间，项目较多，为防止出现混乱，临时写了一些想法（继续思考中）：
一：目的：为了更快、更加方便处理客户临时发现的一些bug;
二：原因：由于目前所有版本都不稳定，在标准版下的修改可能会影响到其他已交付项目的应用。
三：关于版本的处理意见：
1.每交付给客户一套程序时，要在此目录下新建一个文件夹，存放交付时打包所需的所有源代码（一定要包括当时数据库的表结构）；
2.每当客户提出修改意见时，要先在bug管理工具的此项目上做详细记录，然后测试标准版本是否也有类似问题，再根据实际情况在标准版的项目bug中做详细记录；
3.修改时要从服务器上相应的版本下拷贝出完整的一份项目，强烈建议不要在原项目上进行修改；
4.根据客户提出的问题进行修改;
5.修改完后，认真严格测试（注意：不能仅仅测试用户提出的问题，要全面测试所有的功能，以防由于代码复用造成其它功能出现问题）;
6.自己测试完毕，则提交本项目（注意是本项目，暂时还不要提交标准版的）的bug修改；
7.最好再有其他人完整测试一遍（建议：最好有不同的人员来测试）；
8.经确认没问题，则关闭本项目下的bug.
9.如果测试通过则备份原版本（一定要备份），再将本版本用修改后的覆盖（建议：原版本存放一个月后，如无问题可以删除，如果硬盘空间足够大，则可以保留至下一个版本更新时再删除）；
10.按相同的方法修改标准版下的问题（不一定完全相同，有时可能为了达到兼容需要添加额外的东西，根据实际情况，但目的不变，就是解决标准版下出现的相同问题）；
11.自己测试完毕，则提交标准版的bug修改；
12. 再有其他人完整测试一遍（同样建议：最好有不同的人员来测试）；
13. 经确认没问题，则关闭标准版下的bug.
四：好处
1.版本控制工具上的各个项目的代码共享（并非所有代码，只是共同功能的代码），可以达到修改一次，其他通用，而不必每个项目都去更新；
2.保留最新客户处的项目源代码（包括表结构），可以更快更及时地针对用户的问题进行调试修改。