自主研发项目Git代码管理方案

一、 开发环境管理

建议自主研发系统使用以下环境进行开发：
开发工具：MyEclipse 10 （安装git和FindBugs插件）
开发语言：Java（建议使用JDK1.7或者JDK1.8）
Web容器：Tomcat 8.5.23
数据库：MySQL
项目构建工具：maven

二、Git代码管理流程

2.1 总体流程图

总体流程图

（1） 开发人员直接在本地进行代码开发，提交本地的工作区之后可以维护远程develop分支
（2） 到了版本发布日期或者功能全部开发并测试通过，开发负责人创建新的发布分支，将dev分支merge到新建的Release分支；
（3） Git管理员fetch Release分支到补丁机中（Git管理员的本地电脑），出具增量补丁，邮件通知项目组负责人以及补丁发布人员等，补丁发布人员将补丁打入正式环境，正式环境测试通过后，将Release分支与master分支进行合并。

2.2 详细流程

详细流程

（1） 1.1 开发人员进行功能开发前，需拉取相应项目的远程develop分支代码到本地的git仓库以及工作区；
（2） 1.2 开发人员在本地的开发环境中进行代码开发；
（3） 1.3 开发代码编写完毕之后进行开发环境的单元测试，调整并直到测试通过，期间可以随时提交代码到本地git代码库进行版本控制；
（4） 1.4 提交代码前，需先拉取对应项目在远程代码仓库的最新代码到本地库；git工具判断是否存在代码冲突，如果存在冲突，则进入1.5，否则进行1.6操作；
（5） 1.5 通过开发工具中的git插件进行冲突编辑，并解决冲突，详见附件1；冲突解决后进行1.6操作；
（6） 1.6 将本地的代码push到远程git代码库的develop分支，打包补丁，并做好补丁说明和备份，同时发给项目负责人；
（7） 1.7项目负责人根据补丁的代码规范等对开发人员提供的补丁进行代码评审（详见附件2），可回退补丁给相应开发进行整改直至通过评审；评审通过后进入1.8；
（8） 1.8 打补丁的人员按照补丁规范进行检查，检查不通过则回退给相应的人员进行整改。检查通过后，打补丁人员负责备份测试环境代码，并打到测试环境进行测试。业务领域相关问题负责人进行测试，判断是否测试通过，若测试通过，则进行1.91，若测试不通过，进行1.92；
（9） 1.91 补丁测试环境测试通过，项目负责人或者git管理员将develop分支代码更新到“补丁机”，导出相应补丁，进行补丁整合打包，以邮件形式发送给碧桂园信管中心相关负责人和打补丁人员，并添加补丁说明，标注所修改的类或文件。
（10） 1.92 补丁测试不通过，git管理员或项目负责人在develop分支中将测试不通过的补丁内容进行回滚，让开发人员重新进行开发；
（11） 1.10 打补丁人员将正式环境运行代码进行备份，将补丁打入正式环境进行测试。业务领域相关问题负责人进行测试，并判断补丁是否测试通过，若通过，则进行1.11 ，否则进行1.92；
（12） 1.11 补丁生产环境测试通过，git管理员或项目负责人将远程dev分支与master分支进行合并；
（13） 1.12 git管理员或项目负责人将合并之后的代码版本打上版本标签，方便对代码进行版本管理；

2.3补丁规范：

命名：
web项目名称环境名称补丁描述日期作者版本
例如：宿舍管理系统测试环境_房间档案增加批量导入功能2016-12-5周亮_v1，

补丁邮件规范：

邮件标题：web项目名称环境名称补丁描述_日期

邮件正文：
1、 如果需要执行脚本，请注明所需备份的数据库脚本；
2、 补丁改动的功能点以及所需测试的功能点；
3、 如果补丁涉及到平台性的改造，必须告知测试人员进行全场景测试，包括是否影响其他功能模块之类的；

邮件附件：
1、 补丁以压缩包放入附件；
2、 所需执行的数据库脚本不需放入压缩包，直接放入邮件附件即可；

二、Git分支管理

1.1 项目初始化

1. 创建 Group 和 Project ：若项目为新增项目，项目负责人通知Git管理员在Git服务器上面创建对应的Group，并在相应的Group下面创建Project；

2. 创建 Git 用户及分配权限：项目负责人提供该项目的所有开发人员名单，包括姓名全拼、中文名、邮箱等信息，Git管理员根据人员名单创建用户（默认密码12345678），若用户已存在，则直接将用户配置到相应的Group中，完成权限分配。

3. 代码初始化：开发负责人从Git上Clone相应的项目到本地，配置相应的开发环境、使用框架和maven文件等，建立好开发工程标准目录：源代码目录、数据库脚本目录、工程文档目录、元数据目录以及包命名规则文件等；设置好.gitignore文件；将相关修改push到远程Dev分支，提交合并请求，通知Git管理员，合并到Master分支。

1.2 feature功能分支管理

1. 功能划分：开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；

2. 分支创建：开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop

3. 功能开发：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；

4. 分支合并：开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login

5. 分支删除：feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login

1.3 release预发布分支管理

1. 功能划分：开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；

2. 分支创建：开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop

3. 功能开发：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；

4. 分支合并：开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login

5. 分支删除：feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login

Master 和 dev 分支

master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。

master和dev分支

功能分支
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。

功能分支

注意，从各种含义和目的上来看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流没有在这里止步。

发布分支

发布分支

一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。
常用的分支约定：
用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*

维护分支

维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。