分支的使用以及发布说明

分支在VCS(版本控制系统)是一个重要的特性，对于开发人员来说合理的使用分支具有如下优点：
    * 能够快速的进行代码的持续集成
    * 保证各功能／Bug修复的并行开发以及独立发布
    * 更易于从整体管理代码
    * 减少团队代码的冲突

下面会针对发布流程以及分支的相关内容进行逐个说明：
1. 从分支的角度了解开发／发布流程
                                        Hotfix分支
                                             ↑↓
SubFeature分支 → Feature分支 → Develop分支 → Master分支 → Product分支
                                 ↑↓
                           Bugfix分支

(1) 对于SubFeature分支来说是基于Feature分支进行建立的，此类分支非必建分支
     是否需要建立SubFeatureBranch主要应对如下几方面进行考虑：
    FeatureBranch中功能（特性）的粒度的大小；
    FeatureBranch中功能（特性）粒度符合，但是子功能之间无明显“交集”；
    团队成员对SubFeatureBranch的使用无异议；
     注：目前在团队针对SubFeature类型的分支还未进行应用，是否使用以及如何使用将在《分支以及项目发出流程学习会》中进行讨论

(2) Feature分支主要是基于Develop分支建立的，单从词面来看每一个Feature分支应该具有某一个特性
     每一个Feature分支中可能会存在一个或者多个功能点（任务），这里针对这两种情况进行一些非标准型指南：
     a. 分支中只存在一个功能(或任务)
             确认为独立的业务；
             功能独立并且发布时间与其他的功能不一致；

     b. 分支中存在多个功能点(或任务)
            各任务（或功能点）之间存在关联；
            各任务（或功能点）的发布时间基本一致；
(3) Develop分支主要基于Master分支进行创建，此分支基本会处于“非稳定”状态。对应着测试环境，此环境主要供开发人员或者测试人员进行验收测试
(4) Master分支是为主干分支，一个“稳定”的分支，该分支里面代码具备随时可以发布的状态。另外，此分支对应预发布环境（主要供产品人员进行验收以及演示）
(5) Product分支为“杜撰的分支”，此分支代表着生产环境的正式代码
(6) Hotfix分支主要为了修复生产版本的紧急Bug而创建
(7) Bugfix分支在标准分支分类介绍中不存在此分支，此分支主要是为了解决生产版本的非紧急Bug而创建
另外，需要说明的是从整体代码发布流程各个“节点”对应的分支来看，采用了GitFlow／FeatureBranchFlow的混合模式

2. 分支的创建   - 团队在新需求／技术讨论会完毕后就会开始创建相关的分支，分支的创建主要分为两步：
(1) 在Stash中创建分支，具体步骤如下

    由于使用Stash进行远程代码的存储，所以创建人在正常登录Stash并进入对应的项目页面后，点击下图的按钮，选择“Create Branch”,  填写需要创建分支的相关信息并点击  “Create Branch”按钮

(2) 创建对应的本地分支

    由于远程分支已经创建，如果还没有创建对应的本地分支可以进行如下步骤（命令行模式下已经切换到当前项目目录）：
    git pull（进行远程分支信息拉取操作）
    git branch -a（查看是否有对应的远程分支，显示的名称格式为：remotes/origin/分支名）
    git checkout -b 本地分支名 对应的远程分支名（remotes/origin/分支名）
3. 分支的删除
    当一个分支“彻底”无用的时就需要进行删除，有如下几种情况：
    (1) 新的迭代开始后对前一个迭代的县官分支进行删除；
    (2) 针对上线后的Hotfix／Bugfix分支进行删除；

    (3) 一个特性分支合并到另一个特性分支并测试无误后对合并分支进行删除；

    删除分支操作也需要在分为两步骤：
       在Stash中删除对应的分支
       在本地环境删除分支（其中包括本地分支和远程分支信息）
       删除本地环境的分支，主要分为两部分：
      (1) 本地分支，主要使用git branch -d/D 本地分支名
      (2) 远程分支信息，当删除本地分支后使用git branch -a还可以看到对应的远程分支，删除此类分支需要使用git branch -r -d 远程分支名
         注：远程分支名格式为”origin/分支名"，不要使用“remotes/origin/分支名“
      另外，在删除分支的时候如果无法100%确定此分支现在无人使用请和团队每一个人进行核实后再删除

4. 发布流程说明
    对于一个功能或者多个功能的发布都是基于一个Feature分支开始,最后合并到Product分支结束,下面我们按照步骤进行简要说明：
    (1) 将Feature分支合并至Develop分支并且更新到TEST环境，这里需要注意两点：
        要确保TEST环境对应的分支已经切换到Develop分支
        WebGitHook已经配置并且正常运行，具体配置WebGitHook请详见《WebHook的配置以及调整》与《GIT钩子的使用(GitHook)》
    (2) 将Develop分支合并至Master分支并推送至预发布环境，这里需要注意的内容和（1）使一致的
    (3)在预发布环境中切换至Product分支并将Master分支与之合并，然后将其推送至远程分支。最后，在正式环境拉取
        Product分支。现在说明一下为何会进行如此操作。由于前一个发布版本与新版的代码肯定会有所差异，并且如果两个发布时间间隔越长差异会越大。两个版本代码差距越大就意味着在合并时发生冲突的可能性越大。如果正式环境进行合并操作，在出现冲突的时候由于代码处于“需要解决冲突”的状态，又严重影响用户的使用，这是我们不想看到的。为了避免这种情况的发生就需要“换一个地方”将Master分支合并到Product分支，发布人员可以在本地进行合并并且处理冲突，但是这种方式有一个缺点，就是无法让其他开发人员进行测试，因为受制于个人环境。由于预发布环境与正式环境无论从系统还是数据库都保持“一致”，所以在预发布环境进行分支合并与冲突解决最合适，并且在处理完冲突后可以在预发布环境临时将分支切换至Product分支进行测试。

        另外，由于Product分支相当于简易的发布分支。所以针对Product分支操作的权限会控制在1～2个人