第一步代码提交规范

项目组人少项目多，基本是 2 到 3 人负责一个项目，不存在大规模协作开发的问题，且各个项目的开发，测试，预发布，生产环境各不相同。所以，面对当前的情况，我们采取较为宽松的方式进行 git 开发流程的管理。预发布（demo）分支可选，但是有一个底线，除了 feature 分支外其它分支不允许直接提交代码，只能合并。除 master 分支外，其它分支开发新功能及合并代码前必须先合入 master 分支。

包含demo
不包含demo

分支说明

  1. master 分支
    生产分支：master 分支保存的永远是线上使用中的代码，且 master 分支的代码必须保证能正常运行，不允许将代码直接推送到 master 分支，只有测试无误，要发布生产环境时才可以将最新的代码从其它分支合并入 master 分支。

  2. demo 分支（可选）
    预发布分支：测试通过后，将测试分支合并到预发布分支，供项目相关方进行验收，验收通过后可合并到 master 分支进行发布。不允许将代码直接推送到 demo 分支，如果有 bug 产生，到 test 分支拉取 feature 分支修复 bug，修复完成后合并到 test 分支，由测试人员进行测试，测试通过后再由 test 分支合并到 demo 分支。

  3. test 分支
    测试分支：开发人员在开始新版本的开发前，先合并 master 分支的代码到 test 分支，然后再从 test 分支拉取特性（feature）分支进行新版本功能的开发，开发完成后将特性（feature）分支合并到 test 分支。

  4. feature 分支
    特性分支： 用于开发人员开发新功能使用，开发人员可将代码直接推送到特性分支，开发完成后合并到 test 分支。发布上线后可将该分支删除。

  5. hotfix 分支
    热修分支：如果线上版本出现很紧急的 bug 要修复，就需要在 hotfix 分支进行开发，开发前先合并 master 分支的代码，修复完成且测试通过后将代码合并到 master 分支进行分布。

GIT 操作步骤

  1. 当前 master 分支的版本是 0.1.0，现在要进行 0.2.0 的开发，这时候需要将 master 分支合并到 test 分支
    git checkout test
    git merge master

  2. 开发人员从 test 分支拉取 feature 分支进行开发，开发人员可在此分支进行代码的拉取和上传等操作
    git checkout -b feature-0.2.0-a
    或者
    git branch feature-0.2.0-a
    git checkout feature-0.2.0-a

  3. 开发完成后先将 master 分支合并到 test 分支，再将 feature 分支合并到 test 分支，测试产生的 bug 继续在 feature 分支上修改，修改完成后合并到 test 分支，每次合并 test 分之前都必须合入 master 的代码到 test 分支，如此往复
    git checkout test
    git merge master
    git merge feature-0.2.0-a

  4. 测试完毕后，先将 master 分支合入 demo 分支，再将 test 分支的代码合入到 demo 分支 （可选）
    git checkout demo
    git merge master
    git merge test

  5. 相关方在验收完成后将 demo 分支合并到 master 分支进行发布，打 tag 0.2.0 并将 feature 分支删除
    git checkout master
    git merge demo
    git tag -a 0.2.0 -m “publish 0.2.0 version”