一、源代码管理制度（讨论稿） 1、总则 为加强对公司产品、项目开发源代码及相关技术文件的管理，保证项目实施的效率和质量，特制定本办法。 2、适用范围产品、项目开发技术人员和项目实施总监。 3、明确项目：是指通过公司立项审批需要按期实施的项目。 项目实施：是指完成项目的阶段性或具体领域的实施过程，主要包括研发实施和部署实施。 源代码：是指产品和项目开发过程中形成的程序源代码。 技术文件：指支持产品和项目的各种设计文件、操作指南等技术文件。 版本管理服务器：是指公司设立的Subversion（SVN）服务器，供所有开发者使用。 源代码提交：是指开发者通过客户端程序将编译好的源代码上传到版本管理。
2、管理服务器的运行流程。 4、源码日常管理流程 源码管理就是技术开发过程的日常管理，主要包括源码提交、源码审核、异常协调等几个环节。 方案五、源码结构设置 源码结构是指版本管理服务器上存放源码的文件夹结构。 源代码结构的设置由项目执行负责人决定。 源代码结构设置有几个基本要求： 必须设置文档文件夹：在每个独立项目或子项目源代码文件中，至少设置一个 docs 或 doc 文件夹，仅存放与该项目相关的相关技术文档和参考文献数据; 必须考虑支持库：在源代码结构中，应考虑具体项目引用的非标准第三方支持库或框架的存储位置； 必须能够直接编译：源代码结构必须是可直接编译的结构。也就是说，任何新安装的计算机，在安装了必要的开发环境软件后，通过
3、从版本管理服务器查看整套源代码后，应该直接完成编译。 6、500次提交 500次提交是指在项目实施过程中，所有参与开发的技术人员必须在每年U5:00向版本管理服务器提交小日编译的源代码或技术文档。 源代码和技术文档的提交有以下要求： 任何提交都必须对提交的内容进行评论； 提交评论中必须包含的信息项包括：模块或功能（必须与项目实施进度一致）、性质（正常开发、修改BUG、扩展功能）、状态（编码（X%）、调试通过、独立测试通过、联合测试通过）、更新描述（简要描述本次提交涉及的变更） Q 提交备注必须以右图示例格式为准。 留言：最近留言比例：设置更多葫芦升降机：.三惠玉现在站立并生活M到耳到
4、Hl提交的源代码必须编译无错误。 7、530审查 530审查是指项目实施负责人在每次LI上班前，对版本服务器上所有下属技术人员提交的源代码和技术文档进行审查。 源代码审核有以下审核标准： 下属技术人员必须按量提交； 所有提交的材料必须附有符合要求的提交注释； 每个人提交的内容必须与既定的项目实施进度一致； 在审核过程中源码代码编译过程，如果不符合上述任何一个标准，则意味着FI源代码提交时出现异常。 项目实施负责人应立即协调源码代码编译过程，督促未按数额报送的立即报送； 没有提交备注或备注不符合要求的，补充提交备注； 若报送内容与既定项目实施进度不一致，应进行沟通协调，确保每一位参与实施的人员
5、IT运营按照既定计划分步骤进行。 8、进度计划更新项目实施负责人通过530审核和简短沟通，确认执行中的各子任务的实际进度，并据此更新进度计划文件。 9. 存储库布局 存储库根据项目进行布局。 每个项目都构建一个独立的存储库。 项目仓库下设置两个文件夹trunk和branch，分别用于存放原始项目数据和源自原始项目的分支。 物品。 每个项目分支都应该有一个有意义的名称，并在branchs文件夹下以分支名称建立一个子文件夹。 分支文件夹的结构与主干文件夹的结构一致。 trunk文件夹下设置working和locked两个文件夹，其中working为工作文件夹，参与项目的开发者有重写的权限。 锁定的文件夹是
6、项目开发商无权访问最终版本文件夹，项目实施负责人有权重写，质监部门有权检查。 工作文件夹下设置两个文件夹，docs和projects。 docs文件夹存放项目相关的设计文档，projects文件夹存放各个子项目的项目文件夹。 docs和projects文件夹下面的子文件夹结构不限，但对于C/S项目，建议在projects文件夹下设置server和client两个文件夹，分别存放服务端项数据和客户端项0数据分别。 10. 项目的定稿 项目的定稿是指当项目的开发和实施达到里程碑状态或在一定时间表内设定的其他特定状态时，整体提交的分阶段版本。一些已确定的最终版本包括：系统在线调试最终版、内测版、演示最终版、实测版、发布版
7、发布并升级最终版本。 项目的最终版本有以下要求：项目的所有子项目和子模块源代码编译无错误； 编译好的系统可以在线运行； 所有技术文档与源代码一致； 项目定稿版本由项目实施负责人组织实施 源代码库中显示最新版本源代码及工作文件夹下文档一次性提交至锁定文件夹.项目最终确定的建议操作：将锁定文件夹的副本检出到本地文件夹； 将workingdocs和workingprojects文件夹导出到锁定副本文件夹中，覆盖锁定文件夹中的原始文件； >捕获（Commit）锁定的文件夹； 项目最终版本的提交必须附有评论，评论的内容必须包括
8、项目包括：最终版本（在线调试、内测、演示、实测、发布、升级）、版本特性。 应详细描述该版本的功能。 如果是第一个定型版本，该版本的特性应详细列出已经实现的功能，后续定型版本提交的版本特性描述仅陈述新版本相对于之前版本新增的特性版本。 十一. 项目固定版本说明 固定版本是指项目开发和实施过程中必须设定的几个阶段性版本。 在线调试最终版本：是指项目总体设计中的所有子系统、子模块均已完成基础开发，并在开发实施团队内部进行了完整系统的在线调试后的版本。在线调试版本中的各个子系统、子模块不需要完全实现预定的所有功能，也不需要达到预定的设计性能，并且可能存在BUG。 在线调试
9.系统环境，并确认系统总体设计的可行性。 在线调试完成后，开发实施团队应编写系统部署指南草案； 内测版本：指移交给质监部门进行系统测试的版本。 公测版本应该是经过多次在线调试后的版本，在线调试过程中发现的问题都已经解决。 内测版本不一定实现全部功能，但已经实现的功能应该具有基本的稳定性； demo定型版：指经过多次封测，不存在严重缺陷，可以供业务人员向客户推广产品的功能和性能demo的版本。 演示的最终版本不一定实现所有功能，也不一定达到系统既定的设计性能。 测试版本是指经过多次封装和测试，不存在影响正常使用的缺陷，可以在客户真实环境中试用的版本。 最终测试版本应实现全部核心功能，允许有少量原因不明的功能缺失； 发布最终版本：是指经过多次封装测试和实际测试，已经实现了全部既定功能，完全达到既定设计功能的稳定性版本，是项目开发实施的最终结果。 升级定型版本：是指发布后重新发布的改进版本，经过收集整理客户反馈和新需求，经过分析整理，对原有系统进行有计划的改进，升级定型版本在在功能、性能和稳定性方面的要求与最终发布的版本一致。 本制度自实施之日起施行。 2010 年 7 月 7 日
