Git代码管理与发布流程

分支定义与作用：

主干分支：
origin/master：总是代表了生产环境准备就绪的状态的主分支，必须保证与生产环境在正常运行的代码一致。（每次需求上线验收完成后，由开发负责人从dev或Hotfix分支合并至master，其他分支代码严禁直接合并到master分支），每一次上线完成后的合并归档操作都需要打tag

origin/develop：最后一次交付的可以赶上下一次发布的状态的主分支。当develop 分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试并成功上线至现网且代码已经足够稳定时，就可以将dev合并归档至 master 分支。

辅助分支：
feature：新功能开发分支，功能上线后删除，命名规则（feature/版本号(日期)/功能说明(英文)-author） feature要从develop分支拉出，需求开发完成测试通过，确认可正常上线后，代码必须及时合并回 develop 分支。
（严格按规范来说feature分支不能用于上线时的出包编译分支，而是需要在release分支进行上线出包。但由于许多项目组习惯简化流程，该分支也会直接作为上线打包的分支，去掉了release分支的使用，那么此情况下，feature分支发布时要打tag，且必须保证上线时最新的dev代码有合并到待上线的feature分支上，因为feature功能分支开发中可能有其他需求分支上线完成后合并更新了dev分支。具体操作见下文）

release：feature分支测试通过准备正式发布时，用于辅助版本发布的分支，命名规则（release/版本号(日期)/release名称），release要在本次需要上线的版本feature功能全都合并到develop后，从develop拉出，后续灰度或者现网的验收测试的小bug直接在release改，正式发布上线验收完成后需release合并回develop，dev再合并回master；（发布要打tag）

hotfix：现网补丁分支，命名规则（hotfix/版本号(日期)/补丁说明(英文)--author） hotfix要从master的tag出，修复bug后合并回master、develop，当时如果还有待上线的release也要合并回该release分支。

具体开发代码管理流程：

1. 新需求开发与测试

有新的需求或功能点需要开发时，从最新develop分支中拉出一个feature分支
>> git checkout -b [feature name]
完成feature开发后，在该分支进行提测，测试与修复bug在该分支完成。

2. 版本上线

feature分支提测完成后，将feature分支合并回develop准备上线。
>> git checkout develop
>> git merge [feature name]
此时develop分支已经达到了一个可以发布的状态，将最新的develop分支拉出来成为一个release分支。（注意：release分支创建后到上线前这段时间内，发现bug后的修复需要在原先的feature分支上进行修复与提测，测试完成后再从feature分支合并至develop分支，然后develop分支合并至release分支），正式上线时从release分支最新的代码处打上发布tag，进行打包出包部署至灰度或现网环境，进行验收测试
>> git checkout -b release
如验收测试时有小bug需要修复，这时直接在release分支下进行修复演进。如果验收完成上线成功，则需要将release分支合并入develop分支，然后develop分支再合并入master分支，master保持现网最新代码状态，develop分支供下次开发演进。
>> git checkout develop
>> git merge [release name]
>> git checkout master
>> git merge [develop]
如果bug问题很大，当天无法处理完成需要延期上线，则需要将现网代码回滚至master分支状态，把当前release并入develop中，从develop拉出新的feature进行开发重构。重复1，2步骤再次进行版本上线。

3. 处理冲突

当合并分支出现冲突时，需要手动将文件冲突的部分进行修改（开发工具一般都带有辅助合并的功能，比对与处理合并很便捷，具体操作方式按各自开发工具自行百度）。对修改后的文件保存并重新提交。

4.不使用release分支的操作流程

如果简化代码管理流程，不使用release分支时，按照步骤1完成开发与提测后。
版本上线操作为：
将dev分支最新代码合并到feature分支，保证feature分支包含全部已上线版本代码。
在feature分支最新代码处打上发布tag，进行打包出包部署至灰度或现网环境，进行验收测试。
验收测试时的bug直接在feature分支进行修复。
验收完成上线成功后，将feature分支代码合并回develop分支，然后develop分支再合并入master分支，master保持现网最新代码状态，develop分支供下次开发演进。

5. 线上bug热修复

当碰到一些线上意想不到的bug，需要紧急修复时，就直接从master分支拉出hotfixes分支进行修复。
>> git checkout master
>> git checkout -b [hotfix name]
bug修复完毕，打上发布tag，再该分支直接出包部署，上线测试验收通过后我们需要将分支合并到master和develop中去，当时如果还有待上线的release也要合并到该release分支。
>> git checkout develop
>> git merge [hotfix name]
>> git checkout master
>> git merge [hotfix name]

6.特殊情况下的处理

如果有多个不同的feature分支需要同时进行提测与上线。
可在提测前依次将这些feature分支合并回develop分支，分别处理好合并后的冲突。
将develop分支变为多个需求合并后的版本状态后。
直接在develop分支进行合并版本的提测，测试出来的bug在各自的feature分支进行修复与代码提交，然后再合并到develop分支。
测试完成后此时develop分支已经达到了一个可以发布的状态。

此时可直接按照步骤2进行release分支的创建与出包发布上线流程。

如无release分支的流程则可以直接在develop分支打上发布tag并且进行打包出包部署上线操作，验收测试的bug直接在dev分支进行修复。最终验收上线完成后，将dev分支代码合并至master，结束流程。

7.上线完成后的收尾操作

版本需求上线验收完成，代码已归档至master后。feature分支删除。release分支保留（每一次版本上线的记录）。hotfix分支删除。保证git分支树的简洁性。

最后，代码管理也需要养成良好的习惯。
完成一部分功能点后及时提交至远程仓库，代码提交的频率不要太低。
每次提交/合并或其他操作时，都先进行一下pull操作，有冲突及时处理。