git 最佳实践
总结一下日常工作中的git的使用实践
-
使用场景:
- 多人协同开发同一个项目模块
- 需要解决冲突,越早解决冲突越好
- 本地master分支最好经常pull,越频繁的把远程master分支merge到本地Master,越能减少冲突的出现
- git的每次commit都是一个全量数据,svn每次提交都是一个增量数据
- git 的每次commit都应该是一个有意义的可执行的全量代码,而不应该是一些fix bug的提交
- 如果修改了代码还不想commit记录,用commit --amend修改commit记录.
- 合并多个commit可以用git rebase -i
- 慎用git rebase,最好避免使用
-
开发流程:
- 一般会分为master,dev,feature等环境,master专门用来线上发布,每次发布版本必须用master代码,所有人的代码都要提交到master
- 根据需求or功能,本地创建相应分支,例如git branch -b feature/add-id,把本地分支推到远端同名分支,此时远端没有此同名分支,需要git push origin feature/add-id:feature/add-id,此时通过git branch -vv,可以观察到远端分支与本地分支并没有关联,因此需要git push --set-upstream origin feature/add-id,关联远端同名分支,此时完成分支创建并关联远端分支
- 在向远端push代码之前,记得切换到本地master分支并且pull远端最新的master代码,在切换到开发分支,merge master代码,这样做的好处是在pr之后,不需要解决冲突就可以发布代码,一般来说未解决冲突的分支是不允许merge到master的
-
上线流程
- 发布上线之前,代码应该在线上环境经过验证,一般测试环境是线下
- 灰度部署,根据服务器数量进行一定比例的灰度部署
- 灰度期间,注意观察error,告警,服务器qps,tp90,99等指标,与同时间段未灰度的机器对比,与之前同时间段的集群对比
- 出现问题,即使回滚到稳定包,一般稳定包是部署成功的上一个包对应的master代码