git版本控制规范

分支生命周期概览

git.jpg

默认分支

  代码库默认存在主分支(Master)、预发布分支(stage)、集成测试分支(develop)。主分支只用来分布重大版本，所有提供给用户使用 的正式版本，都在这个主分支上发布。
日常开发在功能分支(feature)上完成，测试分支用来做发布之前的集成测试，如需正式对外发布，先将 feature 分支上的代码合并至 develop分支进行测试，再在 stage分支上对 feature 分支进行合并，最后在 Master 分支上对 stage预发布分支进行合并。

临时性分支

  除了默认分支以外，还有一些临时性分支，用于应对一些特定目 的的版本开发。临时性分支主要有:功能(feature)分支、修补 bug(fixbug)分支，这种分支都属于临时性需要，使用完以后，应该删除，使得代码库分支清晰。

分支种类说明

• 集成分支
    分支命名为develop，即集成测试阶段的分支，dev测试环境默认拉取该分支进行发布（DEV环境可对多个并行feature分支合并发布），保证与其他分支进行隔离测试。
• 功能分支
    命名规范为: feature-[功能名称]-x.x.x，开发新项目以特性分支进行开发，默认从 master 分支签出，开发完成进入集成测试后合并至 develop分支。测试完毕后合并至stage分支进行准生成环境测试。
  每周固定发布分支命名规范为feature-[年月]-[周期] ，如：feature-201906-1，代表2019年6月份第一周固定发布分支。
• 修补bug分支
    指软件正式发布以后，难免会出现bug。这时就 需创建一个 fixbug 分支，进行 bug 修补。修补 bug 分支是从 master 分支上面分出来的。修补结束以后，再合并至 develop,stage, master分支。
  分支命名规范采用 fixbug-[特性名称]-[日期戳] 的形式，如fixbug-rentroom-20190628。

临时分支合并流程

fixbug.jpg

临时分支合并至master后必须合并回stage,develop分支，保证三个主分支代码对称。

相关操作

• pull和push
  代码提交之前先更新一下当前的分支，然后在提交本次修改新增的代码。切换到其他分支后也先更新一下代码，进行开发前也先更新一下代码，反正有事没事更新一下当前分支代码准没错。
• merge
  1.本地更新时遇到冲突，不是自己修改的部分以更新的部分为准，自己修改的部分则以自己的为准，如果双方对同一段代码都进行过修改，那么可以通过annotate查看修改者，和他商讨后解决。
  2.merge其他分支时遇到冲突，一般先以左侧的当前分支代码为准，先将其合并到中间的合并版，然后再讲右侧的其他分支的修改项移入，有不清楚的通过annotate查看修改者，和他商讨后解决。

merge结束前可以查看右上角看看还有没有冲突没解决，以及检查一下中间合并版的代码后再apply。