GIT版本库操作手册及管理规范

1、FESCO Adecco公司内部自建系统GIT代码版本库操作手册及管理规范版本第22页 共22页文档版本历史版本作者/修改者日期描述1.0刘传宏2016-01-29草稿1.1刘传宏2016-02-16修正文档中对各版本库的定义及概念【目录】1概述41.1编写目的41.2适用范围41.3名词解释42GIT操作使用说明52.1GIT工具的安装及权限开放申请52.2GIT工具的使用62.2.1从GIT导入项目62.2.2创建分支112.2.3代码提交122.2.4版本切换142.2.5代码同步142.2.6其他153GIT版本库管理规范154GIT版本结构图175GIT代码管理执行流程图181 概述1.1 编写目的本文主要用于对公司内部自主研发的系统进行代码的版本管理，同时指导公司内部开发人员使用GIT工具进行统一的管理规范。本文所形成的规范将作为IT部门开发的标准流程进行管控，不定时的进行线上环境的抽查，各项目架构师也应当以此文进行严格的版本管理及执行监督。1.2 适用范围所有公司内部自主研发的项目。1.3 名词解释UAT环境：用于用户做验收时进行测试的环境，其中数据均为线上生产数据的备份

2、，在未约定与用户进行验收测试的情况下，不对业务部门开放。测试环境：包含所有开发代码的环境，用于提供用户进行培训、演示等用途的临时环境，数据为加密及改版过的测试数据。PRO分支：用于执行ANT脚本进行自动发布的GIT环境，此处的代码必须与生产环境完全保持一致。UAT分支：用于保证系统的完整性，与PRO分支除数据库配置文件不同外，必须完全一致。GIT分支：由开发工程师根据需求所建的分支，由开发工程师从本地GIT资源库推送至公司统一的GIT版本资源库。测试分支：由项目组自行定义的分支，用于管理测试环境的代码版本库，可根据业务部门的用户需求自行合并GIT分支进行打包整合，以提供给BU部门稳定的可用的测试环境。2 GIT操作使用说明2.1 GIT工具的安装及权限开放申请1. GTI插件在ECLIPSE软件的安装及引用：官网下载当前最新版的GIT插件，并放置于ECLIPSE项目插件结构下，ECLIPSE工具安装插件方法可参照官网上相应的教程：http:/download.eclipse.org/egit/updates/2. 配置SSH登陆口令：ECLIPSE程序中，Window-Preferen

3、ces-输入SSH进行配置定位查询。打开配置界面，见下图：注：如图所见，Comment中必须按照公司流程规范填写域账号中对应的用户名，不允许出现不符合公司规范的用户名，如果出现则一律驳回。3. 申请GIT访问权限：第二步完成后，将保存好的口令文件以邮件方式发送给GIT管理员，邮箱为。由GIT环境的配置管理员进行相应的权限开通，管理员在开通前对账号的描述进行审核。不满足公司域账号规范命名的审核直接驳回，要求申请人重新申请处理。以上是GIT插件安装及权限申请的基本流程及方法，员工需要自行完成安装、配置及权限申请。2.2 GIT工具的使用本章节仅描述需要开发工程师按照标准的管理规范所使用到的插件的功能，涉及到代码的合并及提交方式，其余均暂不描述，开发工程师可自行对插件功能进行研究。2.2.1 从GIT导入项目右键Package Explore面板，选择IMPORT，选择Projects from Git，如图所示：点击NEXT，选择CLONE URI，如图所示：点击NEXT，填写项目GIT资源库路径信息等，如图所示（本文以公司ERP为DEMO进行图解）：点击NEXT，选择创建本地资源库的依据

4、版本，如图所示：注：每个项目均会有一个标准待上线的发布版本作为公司内部的标准版本，各项目组在选择版本时如果存在疑问，可咨询项目对应的架构师，确定版本后，只需要勾选已经过确定的唯一版本即可。之后所有的版本将均以此版本的基础上进行提交和开发，如果在项目初期初始化的版本有问题，后续需要额外的进行切换，以此才能保证当前同步下来的版本是目前最新的待上线版本。点击NEXT进行本地资源库的创建，如图所示：注：图中第一个红框处所代表的路径指本地的资源库路径，与WORKSPACE无关，建议不要存放在C盘，一旦由于系统重装等导致C盘遗失的，未提交至生产的GIT代码也同样将无法找回。git与SVN工具不同，它将同步一个资源库放在本地进行管理，在第一次同步初始化时，需要选择一个版本将本地与远程的版本进行关联，之后从GIT更新代码时，如无特殊的配置选择，同步下来的代码版本也均自动以用户初始化选择的版本进行关联和合并。版本的初始化选择如图中第二个红框所示。选择完成后点击NEXT，将会出现一个较长的同步过程，同步时间的长短与项目本身代码的大小有关，等待完成后，将出现如下图所示的界面：选择导入已经存在的项目，点击NE

5、XT，如下图：点击FINISH，后续流程与导入本地项目一致，选择相应的编译版本，加入相应的JAR包文件，后续图略。2.2.2 创建分支按照新制定的开发规范，将来所有的开发将全部在本地以分支的方式进行管理，由开发工程师本地进行维护和统一管控，具体规章制度如后文所描述，本章节描述分支创建的方法及过程。与SVN插件使用方式相同，GIT插件需要对项目进行右键，点击TEAM来操作。通过点击Switch To来切换本地已经存在的分支版本。创建分支，则需要点击New Branch进行操作，点击后将会出现如下图所示界面：点击FINISH后，分支创建成功，此时在项目的GIT后缀提示将变为由用户创建的本地的分支名称。2.2.3 代码提交按照新的GIT管理规范，代码的提交必须通过分支方式进行规范化的提交，由本地的分支提交至远程的分支，由项目的架构师进行代码功能合并，不允许提交在UAT上直接进行合并。与SVN插件相似，代码提交需要通过TEAM窗口进行提交，见下图：点击COMMIT后，将会出现如下框体：其中Commit message处为必填项。此处将有两种提交方式：1. Commit：提交至本地资源库，不推送

6、到服务器上。此时代码的提交仅提交在本地的GIT资源库中，线上无法见到相应的版本。需要重新使用插件的PUSH功能才能提交至远程服务器上。2. Commit and Push：如上描述，提交至本地资源库，同时推送至GIT远程资源库。2.2.4 版本切换主要用于本地资源库中保留的版本的代码切换，用于在某个版本的基础上进行代码的BUG修复，功能二次开发确认等。与2.2.2中描述相似，通过插件的SWITCH TO功能进行版本的切换，注：此处的切换指本地环境的版本，线上版本则需要通过同步后再进行切换。2.2.5 代码同步通过2.2.4的描述，将本地的版本切换为如上文所述的初始化版本，将本地的初始化版本的代码同步到最新的线上版本，操作如下：2.2.6 其他GIT插件的其余功能与SVN插件基本一致，可由开发工程师自行研究及使用。3 GIT版本库管理规范1. 开发工程师在申请GIT权限时，提交的授权口令文件中均需要以公司域账号作为账号名，不允许出现英文名、全名的简称等作为用户名。2. 开发工程师均需要以GIT分支的方式提交代码，每个功能点或需求、BUG等均需要建分支，不允许多个功能或BUG合并后进行代码

7、的提交，GIT分支的创建命名规则为：【类型】【禅道需求或BUG编号】-【任务开始日期（YYYYMMDD）】进行提交，例：REQ 001-20160101。3. 后期管理规范中，所有的代码提交版本均需要与禅道的任务编号进行一对应，开发工程师在创建GIT分支的流程中必须做到描述的清晰。以下几项禅道与GIT的命名类型可作为参考：禅道GIT命名BUGBUG需求REQ自动化测试脚本JUNIT4. 开发工程师需要自觉养成代码同步的习惯，代码提交前尽量做到先同步UAT资源库，拿到最新的线上版本的开发代码，同时避免在提交过程中出现代码冲突。未及时同步导致代码冲突的发生，均自行解决相应的冲突及问题。5. 系统架构师可以根据自身的项目情况指定专人进行以下相应的流程及规范。（以下文中“架构师”表示架构师或其指定的某一个责任人）6. 如上所述，系统架构师后续在项目需求的功能拆解、BUG定义等流程上需要对应的提高，将禅道的任务在拆解过程中，做到更加的可追溯性及原子性。7. 各项目的系统架构师必须对开发工程师进行不定期的管控及监督，未完整清晰描述分支版本的代码不应合并至UAT分支进行发布，违规者需要承担相应的责任。8. 后续所有的功能发布均由项目所负责的系统架构师在上线前统一合并到UAT版本，所有开发人员不允许对UAT版本的代码进行PUSH操作。一旦在不定期巡检中发现有不合规的操作，均需要承担相应的责任。9. 系统架构师的代码合并依据需以每周上线计划进行代码合并，避免功能的误更新导致发布到线上时出现各种异常或问题。10. 系统架构师在代码合并的过程中遇到冲突，需要找到GIT分支创建人协作进行代码的MERGE操作，分支的创建人必须义务的协助处理相应的问题及代码版本冲突。11. 当用户在UAT环境测试验收完成后，系统架构师必须根据业务部门的反馈进行代码的重新整合，验收不上线的功能必须进行回滚操作。系统架构师在上线发布前必须保证UAT环境的代码的完整性，UAT环境的打包必须做到正确无误的发布。12. 系统例行更新发布前一天必须由系统架构师将UAT分支合并至PRO分支，等待ANT脚本的执行进行项目例行更新及上线。4 GIT版本结构图5 GIT代码管理执行流程图-文档结束-

《GIT版本库操作手册及管理规范》由会员1818****572分享，可在线阅读，更多相关《GIT版本库操作手册及管理规范》请在金锄头文库上搜索。