客户端Git使用规范

客户端Git使用规范

1、origin/master是其 HEAD源代码总是代表了生产环境准备就绪的状态的主分支；
2、origin/develop是其 HEAD源代码总是代表了最后一次交付的可以赶上下一次发布的状态的主分支，也把它叫做“集成分支”；
3、每当 develop分支到达一个稳定的阶段，可以对外发布时，所有的改变都会被合并到 master分支，并打一个发布版本的 tag；

一、分支管理规范

原则

1. 每个项目，必须存在master和develop两个分支，develop是基于master开出的集成分支。
2. 保持develop分支只能合并，不能开发原则。
3. 保持master分支只能合并，不能开发原则。

开发阶段分支管理

1、业务需求开始开发时，基于develop开出新分支（不允许在develop上面写代码），命名为version-demand-productType。

1.1：如4.17.0-demand-product，提测时，测试的是该分支包。
1.2：修复开发中的bug，在对应的分支上修改，修改完毕后并提测该分支。
1.3：测试相应分支完毕后，及时将该对应分支合并到develop分支。

2、技术需求开始开发时，基于develop开发新分支，命名为version-tech-feature。

2.1：如4.17.0-tech-memory，提测时，测试的是该分支。
2.2：测试相应分支完毕后，及时将该对应分支合并到develop分支。

3、提测期间，打包基于各自的工程分支。

预上线阶段分支管理
1、预上线时，各自业务端，将本期即要上线所开的分支，合并到对应的develop分支。
2、预上线若有bug修复
3.1：在各自工程的当前分支修复当前bug，并在测试环境，测试bug是否修复。（如若不需要验证，直接走3.2）
3.2：若bug已修复，再次合并到各自工程的develop分支，通过打壳工程包继续验证。

4、预上线期间，打包基于壳工程的当前版本开发分支。

上线发包阶段分支管理
1、各自工程的develop分支，合并到master分支，并打好tag。命名为version版本号。tag即4.17.0
1.1：删除各自业务工程本地开发的所有branch分支。
2、测试基于develop分支打出的包进行验证回归。

5、发包后，如若存在bug修复

5.1：（可认为属测试阶段）从当前业务的develop开出分支，命名为version-bugfix-feature。如4.17.0-bugfix-login，基于当前分支进行打包测试。
5.2：（可认为属预上线阶段）上述步骤测试完毕后，各自工程合并到对应的develop分支，然后基于壳工程当前版本的开发分支进行打包，然后继续测试。（如若不需要验证，直接走5.3）
5.3：（属于发包阶段）上述步骤测试完毕后，将develop分支合并到master，并打出修复tag。基于原来的tag打出一个小version版本号。tag即4.17.1.
5.4：（属于发包阶段）重复发包阶段分支管理各个阶段，打包验证回归。

包发布到市场后的分支管理

1、将壳工程当前的develop分支，合并到master分支，并打好tag。命名为version版本号。tag即4.17.0
2、如若发包到市场后存在bug修复
3.1：基于各自工程的master的tag分支，开出bug修复分支。命名为version-bugfix-feature，如4.17.0-bugfix-login，基于当前分支进行打包测试。
3.2：上述步骤测试完毕后，将该修复分支合并到master，并打出修复tag。基于原来的tag打出一个小version版本号。tag即4.17.2。
3.4：上述步骤测试完毕后，发布市场后，将该修复分支合并到master分支，命名为version版本号。tag即4.17.2。并删除本地修复的版本分支。

tag管理

1、打tag值时，一定遵循附注标签方式，即git tag -a 1.0.0 -m “some commit info”

二、命名规范

1、产品需求分支命名规范：version-demand-productType.
例：4.17.0-demand-product 或4.17.0-demand-universalLinks
2、技术需求分支命名规范：version-tech-feature
例：4.17.0-tech-memory
3、bug修复分支命名规范：version-bugfix-feature
例：4.17.0-bugfix-login
4、tag命名规范：version
例：4.17.0 、4.17.1等