git-术语解析、研发流程

1、常见术语

1.1、基本术语

1.1.1、仓库

代码文件存储的位置，常见的有工作目录->缓存区->本地仓库->远程仓库。

1.1.2、版本

项目开发过程中，使用版本来记录文件在每个阶段的变化内容。

1.1.3、分支

保存文件的一种方式，而且分支之间实现了资源隔离。

1.2、动作术语

1.2.1、获取

从上级仓库位置获取文件到当前位置。

1.2.2、提交

将修改好的文件提交到上级仓库位置。

1.2.3、合并

将某个仓库位置的文件和本地位置的文件组合在一起。

1.2.4、冲突

合并的过程中，由于文件、语意方面的不一致，导致不能正常合并。

1.2.5、解决

对于冲突的场景，进行人为干预，最终达到正常合并的条件。

1.3、其它术语

1.3.1、hook

触发器，我们在做一件事情的时候，会自动触发已定义好的事件。

1.3.2、锁定

对仓库中文件进行安全保护的一种权限设置

2、分支解析

2.1、简介

在一个代码基础上创建分支的能力是版本控制系统最重要的特性。这个操作实在版本控制系统中对选定的代码内容创建一个副本，所以分支其实就实现了一种项目代码资源隔离的方式，保证我们在项目开发的过程
中，组员间之间工作互相不受干扰。分支的主要目的就是帮助项目并行开发。
由于项目开发过程中的代码资源隔离，那么我们就可以基于这种资源隔离的特点，实现项目的不同状态管理，这就出现了多种角色分支。
我们按照日常的使用频率和角色地位的不同，将其分为常用性分支和临时性分支。

2.2、分支流程图

2.3、常用性分支

2.3.1、主分支(master/trunk)

每个代码库有且仅有一个主分支。它是版本库初始化以后自动建立的，默认就是在主分支在进行开发。

2.3.2、开发分支(develop)

项目代码的日常开发所在的分支

2.4、临时性分支

2.4.1、功能分支(feature)

为了开发某种特定功能，从Develop分支上分出来的。临时开发完成后，要再并入Develop

2.4.2、预发布分支(release)

预发布分支，它是指发布正式版本之前(合并到Master分支之前)，进行版本代码测试的临时性分支，测试通过后，就正式发布代码。代码发布完毕后，需要合并到develop和master分支上

2.4.3、修补bug分支(fixbug)

软件项目正式发布以后，难免会出现bug，就临时创建一个bug分支来进行功能修补，功能修补完毕后，在将最终代码合并到Master和相应的Develop。

2.5、分支使用

团队中使用分支的主要原因有以下几种：
   物理上：基于项目代码目录结构配置，即为了文件、组件、和子系统而分支。
   功能上：基于项目多功能配置，即为特性，逻辑修改、缺陷修复、功能递增。
   环境上：基于项目多运行环境，即为开发、测试、预发布、线上环境等。
   组织上：基于项目团队的工作量，即为活动/任务、子项目、角色、群组等。
   流程上：基于项目团队的工作行为，即为支持不同的规范、流程、状态等。
这些分类的分支并不互相排斥，只是在不同场景下我们未来创建分支的一种理由，方便我们的团队工作。

3、研发流程

3.1、研发流程

3.1.1、研发示意图

3.1.2、流程解析

1、从主版本库master中切到本地一个功能分支feature
   注意：必须在主分支持续集成状态为绿色时(代码无问题)，拉取分支
2、基于新功能或bug修改本地功能分支代码
   注意：本地编写代码，按照自己的速度，保证质量
3、对2完成的代码进行本地功能测试
   注意：侧重于组件接口测试
4、验证无问题后，从主版本库中拉取没问题的最新代码，合并到本地功能分支上，并再次执行本地验证
   注意：
   因为本地开发过程中，master分支可能被别人提交过，所以我们提交代码时候不能和新master冲突
   本地测试时间一般不长，如果本地测试过程中，又有人提交新代码到master，必须重复4动作
5、将二次验证后的本地feature分支代码提交到代码主版本库master
   注意：一定要先本地测试成功，而且master分支跟刚才拉取的状态一致
6、代码提交者基于自己提交后的主分支代码触发的持续集成线上构建，直至其成功。
   注意：如果构建失败，必须做最高优先级任务对其进行修复

3.2、软件研发管理流程图