Git版本控制规范

[JeniTurtle]

Git版本控制规范

---

一、分支管理

分支名	环境	备注
master	生产	权限只开放给项目负责人
test	测试	定期回滚到master版本
development	开发	手动rebase master版本
developer branch...	本地	个人开发分支，随意

1. 开发者本地分支：

开发者在本地创建、修改代码后，提交到git仓库，用来备份自己开发的代码。

基于development、test、master分支，可以任意选择一支进行开发，并针对不同的场景，合并到test或development分支，部署后进行测试。

问：为什么不直接在development和test分支上进行开发？
上面提到过，test和development分支都可能会因为自动或者人为的因素回滚到master版本，为了防止不必要的合并和代码丢失，还是用个人开发分支。

2. development分支

开发环境分支，在多个开发者协同工作时，方便联调。

比如A将自己代码提交到development分支，B可以从development分支拉取A提交的代码，开发完成后，统一在开发环境测试。

每次项目上线之后，development分支都需要看情况，由开发者自己决定，何时rebase到master分支，基于线上最新版本继续开发。

3. test分支

测试环境分支，主要供测试人员使用，开发者请勿在测试环境联调。

test分支需要定期还原到当前线上最新的master分支，比如每周的周一和周三晚上12点，测试人员在测试时间安排上，也尽量按照这个周期。

问：为什么test分支要定期自动回滚到master？
说白了就是一个约定，如果跟development分支一样，由开发者自己手动将分支回归到release版本，那么合代码的时候，可能不知道其他开发人员修改的内容，而导致误操作，给测试人员带来不必要的问题，所以不如直接回滚，然后让开发者自己重新提交。

4. master分支

生产环境预发布时，项目负责人需要询问开发人员是否有需要上线的功能，开发人员提供自己的开发分支，该分支必须要基于最新的master版本，并且只能有一个commit提交。

在要求负责人往master合并代码的时候，需要遵守提交规范，不符合规范的提交，会被负责人打回，重新修改后再进行合并。

项目负责人确认项目合并没有问题，进行手动上线。

每次发布都应该打上对应的版本号，以及该版本详细的相关修改内容。

---

二、代码提交规范

开发者本地分支、development分支、test分支，理论上是不限制提交规范，用merge还是cherry-pick都可以，还是以效率为主，因为最终都要回归到master版本，所以只需要在上线提交master分支的时候，才需要对提交规范做限制。

当然，在日常工作中有一个良好的代码提交规范，对开发者而言也是一种对自我要求严格的表现。

master分支代码提交规则：

每一个开发者，需要将自己本次上线修改的所有内容，合并成一个commit。

比如你基于上次master分支进行开发，现在要提交master分支的时候，你总共有10次commit记录，那么你需要先将这10次合并成1个，并将本次功能修改的内容，一一列出，然后提交到master分支。

另外，想git操作自动生成的commit，比如merge、revert生成的记录，一律不允许存在，主要是方便跟踪和管理线上提交记录。

多次提交合并一次的实现方式：

在本地基于你当前提交并push过多次的分支explosion_duang_1，创建一个新的分支，如：
git checkout -b explosion_duang_2。
然后查看commit提交记录，回退到分支最新的一次提交（前提你要先rebase master分支），如：git reset 0bfaad4，注意，别加--hard参数，不然你代码会丢哦！
回退完之后，会发现之前所有的提交过的文件，都重新变成了未提交的，这时，你再重新执行git add files，git commit -m '1、fuck。2、fuck。...'即可。
最后，切换到master分支，git checkout master，合并刚才分支提交的commit记录，git cherry-pick 6cd9616，到此，大功告成！

等等，好像还有一个问题，如果我要把我当前创建的分支提交到远程保存，那不会创建很多分支吗，会导致分支列表很乱。
的确，如果你只想用一个分支，而且在合并一次提交之前，push过多次，那么你在reset和重新add、commit之后，可以通过git push -f命令，强制覆盖远程分支的提交记录。
注意！大写的注意！普通开发人员操作公共分支尽量不要用git push -f，不然容易挨揍。。。。

项目负责人合并上线：

项目负责人合并开发人员分支到master分支时，需要先检查每个开发者的commit提交记录是否合并成一个。

然后进行代码review，如果发现存在问题，要求负责开发的人员进行完善，修改没问题之后，再进行合并，注意使用cherry-pick合并，而不要使用merge。
项目负责人合并完所有人的代码之后，在进行手动上线。

以上，就是git版本管理和发布的规范流程的初定稿，欢迎提问和补充。