GitLab代码开发管理
一,分支管理
GitLab固定三个分支及其关系master-->release-->development,三个分支只有Maintainers允许merge,允许push.
设置方法:Settings-->Repository-->Protected Branches可以添加保护分支策略,如下图:
图1.1分支保护
成员分支:
每个成员须从development分支下创建自己的开发分支,命名规则development_xxx_bugfix或者development_xxx_newfeatures等,xxx代表开发者名字全拼.
二,开发管理
开发提交代码步骤:
1,成员在自己拥有的分支上开发new features或者bug fix
2,完成之后push到自己的分支
3,创建merge request到development分支并指向研发负责人
4,研发负责人收到merge request后进行code review
5,没有问题之后研发负责人merge此次request;有问题的话和开发者说出问题所在,并且关闭此次merge request
图2.1开发提交代码步骤流程
三,发版管理
待测试完成测试后,分支需由研发负责人按照development-->release-->master进行merge,最终master分支保留有本次版本开发的最新最全没有bug的代码
四,tag管理
新版本发布后必须创建tag封版本,方便以后对之前版本和问题的追踪管理
具体步骤:Repository-->Tags-->New tag
图3.1创建tag
Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。
4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程
二、工作原理Git的工作方式:
也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
工程技术部管理工 作流程
5工程技术部管理工作流程 5.1工作管理流程编制说明： 5.1.1编制核心：图纸会审、施工准备、工程进度、工程质量、施工安全、施工成本控制及成本核算、技术管理。 5.1.2编制目的：本工作流程是对公司管理制度在有关具体工作环节中的贯彻落实，而不是制度本身。 5.1.3编制原则：仅对主要工作的重要环节做简明扼要的表述，不作繁杂的细节描述，以便执行人员熟记。 5.2图纸会审工作流程 5.2.1组织工程部与项目部技术人员仔细研读设计文件，找出施工图设计错误或其它矛盾问题，做好会审准备。 5.2.2提请建设单位邀请设计与监理单位，确定会审日期。 5.2.3组织相关人员，准时参加图纸会审，做好会审记录。 5.2.4做好会审结果的落实工作，及时办理技术变更与技术签证、经济签证。 5.3施工准备工作流程： 5.3.1根据工程特点与地域特点及本公司人力资源状况，组建能满足工程管理需要的项目班子。 5.3.2组织召开项目部及相关单位参加的施工准备工作会议，根据工程特征及工地所在地环境，确定施工准备工作范围，明确工作分工，核定时间表。 5.3.3督促检查各部门的工作进展，确保施工准备工作按期完
5.3.4施工准备工作分工原则： a.工程部：负责宏观管理类工作和技术管理类工作。具体包括：施工方案与进度计划的审核，施工图技术交底，各类管理指标的研究确定等。 b.人力资源部：对项目部组成人员的调配或招聘。 c.材料部：根据工地地域的不同，研究制定设备材料采购供应方案（划分分级采购范围及控制办法），确保及时供应。 d.项目部：编制劳动力需求计划，签订施工分包合同。编制设备材料需求计划，组织进场运输。编制施工平面布置图，修建临设、围墙等。编制施工方案与进度计划，确定质量控制点，做好技术交底。以及足已具备开工条件的一切准备工作。 5.4工程进度控制流程： 5.4.1科学合理地进行进度计划的审核，确保可行性，且满足甲方要求。在可能的前提下，工期安排应提前完成，留有余地。 5.4.2进度计划一经批准，不得随意更改，必须全员配合，努力实现。 5.4.3确遇难以克服的客观原因发生，致使进度计划确需修订时，提请总经理同意后方得修订。 5.4.4进度计划修订时，如果不得不延长工期时，必须征得甲方同意。 5.4.5每月25日前，项目部上报当月工程形象进度和下月进度
北京东达悦科技有限公司 软件研发版本管理规范v1.0(草案) 研发部 2009-2-4
目录 文档类别使用对象 (3) 1．引言 (4) 1.1目的 (4) 1.2范围 (4) 1.3术语定义 (4) 1.4版序控制记录 (5) 1.5版本更新记录 (5) 2．版本管理 (6) 2．1版本标识方法 (6) 2．1．1正式版本 (6) 2．2目录结构 (6) 2．3文档的存放 (8) 2.3.1当前版本和历史版本的存放 (8) 2.3.2开发文档的存放 (8) 2.3.3源代码的存放 (8) 2.3.4 SQL语句的存放 (8) 2.3.5发行文档的存放 (9) 2．4权限控制管理 (9) 3．更新管理（版本升级） (9) 3.1版本升级原则 (9) 3.2 新版本的发布 (10) 4．备份管理 (11) 5．用户版本管理 (11) 6．研发部统一管理阶段性版本 (12) 6.1阶段性版本的提交到研发部 (12) 6.2阶段性版本的发布到公司网站上 (12) 6.3各项目组新版本内部及时备份。 (12) 7．版本工具的使用 (13) 7.1研发部采用SVN配置管理工具 (13) 8．各项目组提交文档及源码以及规则 (13) 8.1各项目组需要提交的文档 (13) 8.2目前所管理的产品列表 (14)
9．周报管理制度 (14) 10．风险管理制度 (15) 文档类别使用对象 文档类别 该文档是为东达悦公司提供一个版本管理规范性文件。 使用对象 该文档使用对象为东达悦软件公司研发本部各部门项目经理及版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
技术部工作流程初步方案 目的 随着公司工程项目的增多以及市场对工程项目要求的不断提高，为了有效管理本公司技术部的工程项目实施过程，确保工程项目设计符合公司定位，提高工程项目管理的综合效益，我们需要对工程项目方案设计、初步设计、施工图设计和项目实施跟踪进行细化，以提升工程项目设计品质，降低成本，更好的满足用户需求。同时新产品作为企业在激烈的技术竞争中赖以生存和发展的命脉，它不断为企业的发展壮大注入新鲜血液，它在提升产品优势、开拓新市场、提高经济效益等方面起着决定性作用。为了完善新产品的开发流程，规范新产品的开发过程，优化新产品开发过程管理。同时使各位同仁的工作事项更加明细，职责更加明确。最终达到规范管理、提高总体工作效率的目的。根据本公司的实际情况制定一系列管理制度和工作流程。 技术部部门工作职责 1.负责建立和完善部门管理制度；贯彻执行国家及行业主管部门的有关法律、法规。 2.负责并组织公司各工程项目的施工图设计；负责外来图纸的会审、施工图纸及相关文件的完善、齐套工作；负责在施工过程中进行技术指导和检查，以及竣工验收的技术指导工作。 3.负责向生产部提供产品制作所需的技术资料、图纸，解决制作过程
中产生的技术疑问。 4.主持新产品设计、试制、改进等工作。 5.协助采购部对工程材料、设备选型，提供材料设备的技术参数要求，与采购部共同进行初选。 6.为工程投标提供技术支持，与用户进行技术交流，并解答用户提出的与产品技术相关问题。 7.负责配合质量检验部门对不合格的控制，对质量问题的调查、分析和处理以及纠正和预防措施的检查落实。 8.负责技术类资料的发放、存档保管工作。 9.新产品施工前的技术交底工作。 10.负责完成领导交办的其他工作。 设计文件编制与日常管理 为了保证图纸的完整性、标准性和统一性，确保设计和生产工作的顺利进行，制图要符合GB/T4458.1-2002机械制图标准，按比例绘图。此外，还要符合以下要求。 1、软件版本要求为了统一制图软件版本，要求存入电脑的图纸是AUTOCAD2007或CAXA2007，能够用AUTOCAD2007或CAXA2007打开和编辑。 2、标题栏和明细栏 a.为了保证图纸的准确性和合理性，标题栏要有设计、绘图、审核、批准内容。
源代码管理制度 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 1.3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。在SVN库中设置用户，并为不同用户分配不同的权限，适合工作的最小访问权限。
要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号：终端型号是硬件标识号，也唯一的标识了我们的项目。版本号：由“＜主版本号＞.＜次版本号＞.＜修订号＞”三段组成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布，终端软件的bug的记录和统计，主要是针对于版本号的，测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug，bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后，我们会统计新的版本号解决了上一个版本号中的哪些bug，以及增加了哪些新功能，等等。 内部修订号：也就是“应用程序的源代码的svn修订号”，主要是由软件部和测试部内部来使用，内部修订号唯一标识我们的终端软件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码，目的是为了软件排错使用。 另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。 由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本号发布后，需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部修订发生变化。 3、软件bug记录、管理和统计 软件bug的记录、管理和统计主要以版本号为基准，但为了软件开发人员能够找到bug
信息技术部工作流程 一、IT 专业技术岗位考核流程 (1) 二、版本发布管理流程 (2) 三、测试管理流程 (5) 四、对外数据报送工作流程 (8) 五、基础运营管理流程 (11) 六、计算机桌面管理流程 (13) 七、系统开发流程 (17) 八、数据库管理流程 (19) 九、网络管理流程 (21) 十、系统维护流程 (25) 十一、项目管理流程 (27) 十二、信息安全管理流程 (31) 十三、需求管理流程 (35) 十四、需求变更管理流程 (38)
一、IT专业技术岗位考核流程 1、各部门权限情况 总公司信息技术部 提取机构IT工作绩效数据；数据结果确认与分析；实施考核评价；公示考核结果分公司IT 根据总公司要求上报工作月报 分公司IT管理部门 分公司IT考核结果确认 2、流程图 3、流程说明
. 二、版本发布管理流程 1、各部门权限情况 分公司管理部门 进行人员培训及政策宣导；进行系统发布反馈 总公司管理部门 提交上线申请；审批版本上线计划；协调分公司进行政策宣导及操作培训 分公司IT 配合进行发布实施；核实发布反馈 信息技术部 提交、调整、颁布发布计划；实施版本发布，分析发布反馈信息；提交上线报告2、流程图
3、流程说明
1、上线计划是否与开发版本存在冲突 2、上线前是否完成政策宣导与培训 3、上线机构是否得到确认，是否需要回 滚版本
三、测试管理流程 1、各部门权限情况 分公司管理部门 进行用户测试；进行测试反馈 总公司管理部门 进行用户测试；组织、协调分公司开展用户测试工作；进行用户测试进度跟踪；签署测试验收报告；提交上线申请 分公司IT 配合测试工作—程序安装、权限设置等；核实测试反馈 信息技术部 负责内部集成测试；向分公司提供测试程序；收集反馈用户测试信息；分析用户测试反馈2、流程图
1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)
1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
技术部工作流程及管理售前——售中——售后项目实施阶段工作流程： 一、流程图 售前
售中
售
二、工作流程说明 1、根据业务部门提出的服务请求，提交给部门经理，由部门经理结合当前的工作安排 以及申请服务的技术类型，合理的安排相应的技术人员受理该项服务（设计服务）。 2、根据来自业务部门对整个项目的了解情况，以及技术部门对方案设计数据的需求情 况决定是否需要对用户进行上门调研。 2.1 需要项目上门调研。由集成部部门经理指派响应的技术人员配合业务部上门对客 户的情况进行了解，填写项目调研、现场勘察的各种表格。 2.2 不需要项目上门调研。业务方已经充分了解了用户的需求，由业务方填写用户需 求的表格。 3、将项目调研的各种数据进行汇总整理，结合项目的需求开展项目讨论，成立项目小 组，根据项目的类型指派相应技术人员进行方案的设计，相关业务人员配合，完成方案设计。 4、技术人员在方案设计报告表要求的时间设计解决方案，在设计过程中充分结合业务
部门人员，出现设计目标不明确或数据不清楚的情况及时联系甲方负责人，进行项目补充调查。 5、方案设计完成后，由方案设计人员发起，技术主管主持、技术人员以及相关业务人 员参加的项目设计方案讨论会，着重对方案的可行性、设备选型等情况进行审核，最终确立技术方案，由业务人员和客户签字确认。 6、部门经理组织相关技术人员开展项目组织会议，成立项目实施小组，安排负责人， 根据合同工期要求编写施工组织计划与施工方案。 7、进入项目管理阶段，结合项目管理方案对项目进行管理。 8、进行项目准备会 9、召开项目启动会议 参加部门：技术部、业务部、财务部、采购部、制造部。 需明确的会议议题： ◆成立项目小组并且明确分工、职责与负责人 ◆确立施工的起始时间 ◆制订项目准备阶段的时间计划表 ◆项目施工人力资源计划 ◆项目实施时间计划 ◆材料及设备采购与运输计划 ◆车辆及后勤支持计划 ◆部到货验收 ◆项目人员一览表 材料设备采购申请单 10、系统集成部门施工前准备会 由项目负责人明确外出施工人员，需外出的施工人员向不需要外出的员工交半手头遗留的工作，项目负责人对施工人员进行分工、分组，安排负责人。向施工人员讲解施工方案、施工组织计划与施工安排，强调施工组织纪律。 准备施工工具。（包括各种软件工具，系统所用的组件） 准备施工用管理表格。 后勤、车辆的准备。 填写出差、外出申请单。 施工管理相关表格： 出差、外出申请单 工程用工具清单 设备到货部验收单 施工人员工作日志 施工情况报告表 设备安装记录 设备调试报告 11、到达甲方施工现场 首次与甲方项目负责人接洽，向甲方申请施工，进行施工材料与设备的接货，填写部到货验收单，并且以最短的时间以email或传真的形式发给公司商务部门与财务部门。
XXXXXXXX 代码版本管理规范
历史版本
目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)
1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试
.. '. 部门职能技术部 部门名称：技术部主管岗位：技术总监 上级部门：生产部上级主管：总经理 部门结构：技术总监-技术工程师-技术员-技术部内勤 部门本职： 负责公司技术建设及管理，为公司经营管理提供有效的技术支持 部门目标： 以客户的需求为工作目标，即设计的产品要求款式多样、品质优良、低成本、容易生产、符合安全规定。 主要职能： 1.负责制定公司管理制度。负责建立和完善产品设计，新产品的试制、标准化技术规程、技术情报管理制度；组织协调督促有关部门建立和完善设备、质量等管理标准及制度 2.组织和编制公司技术发展规划，编制近期技术提高计划；编制长远技术发展和技术措施规划并组织对计划、规划的拟定、修改、补充、实施等一系列技术组织和管理工作 3.负责制定和修改技术规程，编制产品的使用、维护和技术安全等有关的技术规定 4.负责公司新技术的引进和产品开发工作的计划、实施，确保产品品种不断更新和扩大 5.合理编制技术文件，改进和规范工艺流程 6.负责制定公司产品的企业统一标准，实现产品的规范化管理 7.编制公司产品标准，按年度审核、补充、修订定额内容 8.认真做好技术工艺、技术资料的归档工作。负责制定严格的技术资料交接、保管工作制度 9.及时指导、处理、协调和解决产品出现的技术问题，确保经营工作的正常进行 10.负责编制公司技术开发计划，抓好管理人才培养，技术队伍的管理。有计划的推荐引进、专业的技术人员，搞好业务培训和本部门管理工作 11. 负责组织实施工艺分析及工艺改进工作，持续改进制造过程质量，降低成本。 12.负责制度管理制度的制定、检查、监督、指导、考核专业的管理工作 新产品开发 1.1新产品实现的立项策划 1.2新产品的外观功能设计及造价控制和开发的控制及编制各类技术文件 1.3新产品制造过程中的技术攻克及造价成本节约 1.4新产品的实验测试（技术总结报告、实验测试报告、性能测试报告、成本核算报告）1.5新产品技术归档及展示（如有技术创新专利的申请） 管理权限： 1、对企业内部设计的各项图纸有审核、审批权。 2、对经本岗位审核的各项技术资料、图纸的准确性、准确性负责 3、对本岗位设计的技术文件的正确性、准确性负全责。
1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)
1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
部门职能 技术部 部门名称：技术部主管岗位：技术总监 上级部门：生产部上级主管：总经理 部门结构：技术总监-技术工程师-技术员-技术部内勤 部门本职： 负责公司技术建设及管理，为公司经营管理提供有效的技术支持 部门目标： 以客户的需求为工作目标，即设计的产品要求款式多样、品质优良、低成本、容易生产、符合安全规定。 主要职能： 1.负责制定公司管理制度。负责建立和完善产品设计，新产品的试制、标准化技术规程、技术情报管理制度；组织协调督促有关部门建立和完善设备、质量等管理标准及制度 2.组织和编制公司技术发展规划，编制近期技术提高计划；编制长远技术发展和技术措施规划并组织对计划、规划的拟定、修改、补充、实施等一系列技术组织和管理工作 3.负责制定和修改技术规程，编制产品的使用、维护和技术安全等有关的技术规定 4.负责公司新技术的引进和产品开发工作的计划、实施，确保产品品种不断更新和扩大 5.合理编制技术文件，改进和规范工艺流程 6.负责制定公司产品的企业统一标准，实现产品的规范化管理 7.编制公司产品标准，按年度审核、补充、修订定额内容 8.认真做好技术工艺、技术资料的归档工作。负责制定严格的技术资料交接、保管工作制度 9.及时指导、处理、协调和解决产品出现的技术问题，确保经营工作的正常进行 10.负责编制公司技术开发计划，抓好管理人才培养，技术队伍的管理。有计划的推荐引进、专业的技术人员，搞好业务培训和本部门管理工作 11. 负责组织实施工艺分析及工艺改进工作，持续改进制造过程质量，降低成本。 12.负责制度管理制度的制定、检查、监督、指导、考核专业的管理工作 新产品开发 1.1新产品实现的立项策划 1.2新产品的外观功能设计及造价控制和开发的控制及编制各类技术文件 1.3新产品制造过程中的技术攻克及造价成本节约 1.4新产品的实验测试（技术总结报告、实验测试报告、性能测试报告、成本核算报告）1.5新产品技术归档及展示（如有技术创新专利的申请） 管理权限： 1、对企业内部设计的各项图纸有审核、审批权。 2、对经本岗位审核的各项技术资料、图纸的准确性、准确性负责 3、对本岗位设计的技术文件的正确性、准确性负全责。
No table of contents entries found.
1.0工作流程图 1.1 一般工作流程图（零配件和批量较小技术等级）： 1.2项目工作流程图（大批量、成套产品研发和项目开发工
作）：
2.0工作任务说明 2.1一般工作任务 2.1.1指令传达者：总经理、副总经理、营销部（以任务最初传达者为准） 2.1.2 责任者：技术部相关组负责人 2.1.3要求：内容较清晰，有明确的名称、规格、数量、订单号、期限 2.1.4依据规范：银川怡祥矿山机械制造有限公司订单评审及过程控制表 2.1.5结果：产生《订单评审及过程控制表》 2.1.6说明：《订单评审及过程控制表》第一接单人为技术部相关项目组，有相关项目组负责人根据订单确定是否有图，并对图纸进行审核签字确认，无图纸的按照一般工作流程执行。 2.2制订实施计划 2.2.1责任者：技术部相关负责人 2.2.2要求：根据人员、环境、项目要求制定计划，制定的计划需有较高的可控性及可行性。 2.2.3依据规范：一般通用规则和客户要求（与客户充分沟通）。 2.2.4结果：完成本部门责任范围《订单评审及过程控制表》，《月度工作登记表》 5、说明：认真填报《订单评审及过程控制表》，《月度工作登记表》为积分制考核做好基础工作，为公司技术部门规范化管理和推动图纸技术要求完善做好准备，为公司生产活动有序、顺利开展打下基础。 2.3分配工作任务 2.3.1责任者：技术部相关项目负责人 2.3.2要求：根据项目需要以及技术人员能力合理分配工作任务与时间。 2.4用户调研 2.4.1责任者：项目负责人/设计人员 2.4.2要求：按照用户方（使用人员、产品技术人员、部门负责人）描述和介绍总结用户要求，根据上述要求进行图纸设计，有必要报送客户进行审核签字。 2.4.3依据规范：用户需求、规格说明；设计规范、通用要求。
[键入文字] 文件编号:XWQMS-CM-TEM-01 版本号:1.1 软件源代码版本管理与发布 版本：1.0 日期： 2010-9-9 欣网视讯 | 天智互联
修订记录
目录 修订记录 (2) 1.引言 (4) 1.1.目的 (4) 1.2.术语 (4) 1.3.参考资料 (5) 2.软件版本管理 (5) 2.1.版本阶段说明 (5) 2.2.版本命名规范 (5) 2.3.版本号修改规则 (5) 2.4.SVN版本库分支与合并策略 (6) 2.4.1.版本库管理说明 (6) 2.4.2.版本库操作说明 (6) 2.4.3.各种源码变动时，版本库操作方案 (7) 2.4.4.版本库发布模式 (9) 2.5.版本号发布 (13) 2.5.1.版本发布追踪表 (13)
1.引言 1.1. 目的 该文档是配置管理计划的一部分，主要用于源代码版本管理与发布。也可用于项目配置管理与发布。该文档使项目组成员熟悉并按文档约定执行版本管理与发布。该文档列举在开发过程中会出现的开发情况，规范在开发过程中分支的类型，何时分支、何时合并。该文档根据实际项目操作实践处于不断完善中。 应该此方案最基本的前提是需要熟悉SVN客户端操作。 1.2. 术语
1.3. 参考资料 《Version Control with Subversion》 《SMOP文档格式定义规范》 2.软件版本管理 2.1. 版本阶段说明 * Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。 * Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。 * RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。 * Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下， Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。 2.2. 版本命名规范 软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号+希腊字母版本号+SVN最后修订版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.20100409_beta_334。 2.3. 版本号修改规则 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目经理和技术主管决定是否修改。
目录 1 Visual Studio环境下源代码版本管理 2 Eclipse环境源代码版本管理 3体会
1Visual Studio环境下源代码版本管理 1.1SubVersion+TortoiesSVN的配置 1.1.1安装SubVersion 。（下载地址： https://www.doczj.com/doc/114375055.html,/servlets/ProjectDocumentList?folderID=8100&exp andFolder=8100&folderID=91），例如我安装到D:/SVN/SubVersion 1.1.2安装TortoiseSVN。（下载地址：https://www.doczj.com/doc/114375055.html,/downloads），这是一个SubVersion的图像化管理工具，没有它也可以，但是管理SubVersion需要使用命令行的形式，安装过TortoiseSVN可以在右键菜单出现相应的选项。例如我安装到了D:/SVN/TortoiseSVN 1.1.3建立版本库（repository）。这点和VSS一样，我们需要一个库来存放版本信息。创建方式有两种通过SubVersion的命令行或者通过TortoiseSVN的图形界面来创建。我们就直接通过TortoiseSVN创建，例如我想在D盘建立一个文件夹SVNServices 用来放版本库，然后在其中建立一个EMIData的文件夹作为我的项目EMI的版本库，这是我对EMIData点击右键--TortoiseSVN—Create Repository here 即可将EMIData最为一个版本库，这是你会发现EMIData文件夹中多了很多的文件。 1.1.4启动SVN服务。到这里我们的SubVersion其实还没有启动，我们在cmd命令行输入：svnserve –-daemon –-root D:/SVNServices这样我们就可以启动SVN并且以D:/SVNServices作为根目录。这里我要指明几点，第一就是输入的命令中两处都是两个‘-’，也就是‘--’而不是‘-’；第二点就是启动后cmd窗口使不能关闭的，
? 技术部工作流程图
技术工作流程与责任编制 责任部门 / 责任人的职责分工与审核权限划分 工程部 采购部 总经理 技术部 业务部 客户 开始 阶 段
1 客户提出工程订 单需求 D1
4 现场查看
3 工程订单受理
2 发出正式书面 联络
5 1.信息回馈业务 2.方案、成本预算 提出 No
6 正式报价提出
No 审核 初审
D2
Ok
7 相关资料提交至 客户 审核
9 材料采购 10 施工
8 汇总、整理 组织相关部门会 议检讨
Ok
D3
结束
? 技术部工作流程说明
控制事项 详细描述及说明
1．客户需求部门根据相关规定及实际需求提出整改计划 D1 2．客户应以书面形式发出正式联络函、其中需对需求日期、质量要求等提出说明
3．业务部受理客户提出需求，通知技术部前往现场查看实际情况 4．技术部现场查看后回馈业务部相关信息 5．技术部拟定项目方案和完成成本预算清单后提交业务部 阶段 控制 D2 6．业务部根据技术部提供报价清单进行报价，所报价项目及单价需参考之前已验收完成的项目； 不得出现同单品单价不一的情况； 业务部对方案及最终报价进行初步核实确认之后提交总经理最终 审核 7．总经理审核通过后提交客户作最后确认及签回追踪 8．报价单签回后召集相关部门进行施工前会议以及分别对采购部和工程部发布材料申请要求以及 D3 施工预备要求 9．采购部按照审批后的“采购申请单”进行采购 10．工程部按照该项目总要求进行施工 应守 相关 规范 参照 ?《员工各岗位职责表》 规范 规范 ? 内部审核制度 ? 采购申请制度
? 工程报价单 文件资料 ? 采购申请单
责任部门 及责任人
? 技术部、业务部、采购部、工程部 ? 总经理、技术总监、工程经理、业务跟单、采购员
源代码管理制度（讨论稿） 一、总则 为了加强公司产品、项目开发源代码及相关技术文档的管理，进而确保项目实施的效率和质量，特制定本办法。 二、适用范围 产品、项目开发技术人员及项目实施负责人。 三、定义 项目：是指通过公司立项确定需要按期实施的项目。 项目实施：是指为完成立项项目进行的阶段性或特定领域的实施过程，主要包括研发实施和部署实施。 源代码：是指产品、项目研发过程中所产生的程序源代码。 技术文档：是指产品、项目配套的各类设计文档、操作手册等技术性文档。 版本管理服务器：指公司架设供所有开发人员使用的Subversion(SVN)服务器。 源代码提交：指开发人员通过客户端程序将所编写源代码上传至版本管理服务器的操作过程。 四、源代码日常管理流程 源代码管理是技术研发过程的日常管理，主要包括源代码提交、源代码审阅、异常协调等几个环节。
准备 源代码结构设定编码、撰写文档 500提交 530审阅 审阅异常？ 异常协调进度计划更新 是 否 五、 源代码结构设定 源代码结构是指源代码在版本管理服务器上存放的文件夹结构。源代码结构的设定由项目实施负责人决定。 源代码结构设定有几项基本要求： 必须设置文档文件夹：每一个独立项目或子项目源代码 文件内，至少设定一个docs 或doc 文件夹以存放仅与该项目相关技术文档和参考资料； 必须考虑支持库：源代码结构中，应考虑具体项目所引 用的非标第三方支持库或框架的存放位置； 必须可以直接编译：源代码结构必须是可直接编译结
构。即任何一台新装计算机，在安装了必要的开发环境软件以后，通过从版本管理服务器上签出整套源代码后，应该可以直接完成编译。 六、500提交 500提交是指项目实施期间，所有参与开发的技术人员，每日5:00必须将当日所编制的源码或技术文档提交至版本管理服务器。 源代码及技术文档提交有如下几项要求： 任何一次提交都必须对所提交内容进行注释； 提交注释必须包含的信息项包括：所属模块或功能（必须与项目实施进度计划一致）、性质（正常开发、修改BUG、扩展功能）、状态（编码中（x%）、调试通过、独测通过、联测通过）、更新说明（本次提交所涉及修改部分的简要说明）。 提交注释必须以下图示例格式为准。 所提交源码必须是编译无错版本。 七、530审阅 530审阅是指项目实施负责人，每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。 源代码审阅有以下几点审阅标准：
代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。
软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言 .............................................................................. 1.1目的............................................................................. 1.2范围............................................................................. 1.3术语定义......................................................................... 1.4版序控制记录..................................................................... 1.5版本更新记录..................................................................... 2版本管理........................................................................... 2.1流程图........................................................................... 2.2版本命名......................................................................... 2.3版本升级......................................................................... 2.3.1版本升级原则................................................................. 2.3.2新版本的发布................................................................. 2.4目录结构......................................................................... 2.5文档的存放....................................................................... 2.5.1文本文件的存放............................................................... 2.5.2源代码的存放................................................................. 2.5.3发行文档的存放 (9) 2.6权限控制管理..................................................................... 3备份管理........................................................................... 3.1源文件备份....................................................................... 3.2库文件备份....................................................................... 4用户版本管理....................................................................... 5版本工具的使用..................................................................... 5.1配置管理工具..................................................................... 5.2CVS的使用 ....................................................................... 5.2.1常用命令..................................................................... 5.2.2简单操作..................................................................... 5.2.3版本分支管理.................................................................