- 常见术语
- 基本术语
仓库： 代码文件存储的位置，常见的有工作目录->缓存区->本地仓库->远程仓库。
版本： 项目开发过程中，使用版本来记录文件在每个阶段的变化内容。
分支： 保存文件的一种方式，而且分支之间实现了资源隔离。- 动作术语
获取： 从上级仓库位置获取文件到当前位置。
提交： 将修改好的文件提交到上级仓库位置。
合并： 将某个仓库位置的文件和本地位置的文件组合在一起。
冲突： 合并的过程中，由于文件、语意方面的不一致，导致不能正常合并。
解决： 对于冲突的场景，进行人为干预，最终达到正常合并的条件。- 其他术语
hook： 触发器，我们在做一件事情的时候，会自动触发已定义好的事件。
锁定： 对仓库中文件进行安全保护的一种权限设置。
- 分支概念
- 分支简介
在一个代码基础上创建分支的能力是版本控制系统最重要的特性。这个操作实在版本控制系统中对选定的代码内容创建一个副本，所以分支其实就实现了一种项目代码资源隔离的方式，保证我们在项目开发的过程中，组员间之间工作互相不受干扰。分支的主要目的就是帮助项目并行开发。
由于项目开发过程中的代码资源隔离，那么我们就可以基于这种资源隔离的特点，实现项目的不同状态管理，这就出现了多种角色分支。
我们按照日常的使用频率和角色地位的不同，将其分为常用性分支和临时性分支。- 常用性分支
主分支(master/trunk)
每个代码库有且仅有一个主分支。它是版本库初始化以后自动建立的，默认就是在主分支在进行开发。开发分支(develop) 项目代码的日常开发所在的分支- 临时性分支
功能分支(feature)
为了开发某种特定功能，从Develop分支上分出来的。临时开发完成后，要再并入Develop预发布分支(release)
预发布分支，它是指发布正式版本之前(合并到Master分支之前)，进行版本代码测试的临时性分支，测试通过后，就正式发布代码。代码发布完毕后，需要合并到develop和master分支上修补bug分支(fixbug)
软件项目正式发布以后，难免会出现bug，就临时创建一个bug分支来进行功能修补，功能修补完毕后，在将最终代码合并到Master和相应的Develop。- 使用分支的原因
团队中使用分支的主要原因有以下几种：
- 物理上：基于项目代码目录结构配置，即为了文件、组件、和子系统而分支。
- 功能上：基于项目多功能配置，即为特性，逻辑修改、缺陷修复、功能递增。
- 环境上：基于项目多运行环境，即为开发、测试、预发布、线上环境等。
- 组织上：基于项目团队的工作量，即为活动/任务、子项目、角色、群组等。
- 流程上：基于项目团队的工作行为，即为支持不同的规范、流程、状态等。
这些分类的分支并不互相排斥，只是在不同场景下我们未来创建分支的一种理由，方便我们的团队工作。
- 代码开发流程
代码开发标准流程
项目团队在启动项目开发工作之前，应该共同约定的一个行为规范，避免团队协作开发的过程中出现意外，只要是与代码相关的操作，我们的代码开发工作步骤就应该是这样：
这张图是持续集成六步提交法。这是团队开始启动这个试点项目时共同约定的一个行为规范。只要是与代码相关的操作，你的工作步骤就应该是这样的。
- 从主版本库master中切到本地一个功能分支feature
注意：必须在主分支持续集成状态为绿色时(代码无问题)，拉取分支- 基于新功能或bug修改本地功能分支代码
注意：本地编写代码，按照自己的速度，保证质量- 对2完成的代码进行本地功能测试
注意：侧重于组件接口测试- 验证无问题后，从主版本库中拉取没问题的最新代码，合并到本地功能分支上，并再次执行本地验证
注意：
因为本地开发过程中，master分支可能被别人提交过，所以我们提交代码时候不能和新master冲突本地测试时间一般不长，如果本地测试过程中，又有人提交新代码到master，必须重复4动作- 将二次验证后的本地feature分支代码提交到代码主版本库master
注意：一定要先本地测试成功，而且master分支跟刚才拉取的状态一致- 代码提交者基于自己提交后的主分支代码触发的持续集成线上构建，直至其成功。
注意：如果构建失败，必须做最高优先级任务对其进行修复
- 小结
分支种类：常见(master/develop),临时(feature、release、bugfix)
为什么用分支：物理、功能、环境、组织、流程
代码提交流程：拉取、开发、测试、拉取+测试、合并、测试、发布
