• Git使用规范


    Git使用规范

       

    项目

    本规范参考gitflow模型,以解决以下开发到发布流程中可能出现的情况及问题,持续完善中

    • 并行开发,代码互相糅合
    • 长期任务,代码无法及时提交、更新或暂停搁置
    • 测试阶段,其他版本的开发及测试推进
    • 各稳定版本副本的保存以及版本回滚
    • 临时紧急任务、版本发布后紧急修复与当前代码的冲突

    Git及Gitfow相关知识

    《Pro Git》
    《浅谈 Gitflow》

    1. 概念

    固定分支

    master分支:仅存储每个上线的稳定版本,禁止提交
    develop分支:开发、测试流程的主干分支,应提交完整、可发布的代码

    临时分支

    feature分支:由开发人员自行从develop分支创建,下一版本无法上线的特性必须创建feature分支进行开发,feature分支应通过自测正常使用后合并至develop分支等待发布
    release分支:需要发布内容均提交至develop分支后从develop分支拉取并进行测试,对应开发人员针对测试反馈于该release分支进行修复改进,直到测试通过并发布,将该分支所修复的问题合并回develop分支,并提交至master分支记录版本tag
    hotfixs分支:紧急上线、紧急修复分支,由当前master分支最新稳定版本拉出,修复或增加特性后提前上线,将修改合并回master分支以及develop分支

    2. 流程

    首先参考下图


    master、develop为两条固定存在的分支。各自开发任务应当视任务上线计划情况,于develop分支拉取feature分支进行开发,可确定于上线版本提测前快速完成的小规模任务亦可直接于develop分支进行开发。但需注意,develop分支只允许提交完整、通过自测可执行并且将于该版本发布的代码,所以建议大部分情况下开发任务独立创建分支进行开发。

    2.1常规开发

    • 更新至develop分支最新节点并在该节点拉取自己的feature分支
    • 在feature分支完成开发,自测(可以利用个人开发环境辅助测试)
    • 自测通过确定发布后将feature分支合并至develop分支,尚未到达提测时间可于develop分支部署公共开发环境进行预先测试
    • 到达提测时间由负责人员于develop分支拉出release分支进行集中测试,分支成员为该版本提交发布代码的成员,未能于该时间节点的代码将延迟至后续版本发布
    • 集中测试过程中出现的问题和优化项只在该release内进行优化、修复,直至测试通过于该分支的最终节点发布上线版本,期间可持续将修复完成的部分合并回develop分支
    • 将release分支在测试过程中的修复和优化项合并回develop分支,并将master分支快速指向release分支的最终节点,记录该版本tag

    2.2紧急发布

    • 更新至master分支最新节点拉取hotfixs分支
    • 在hotfixs分支完成紧急发布内容
    • 发布并将修改内容合并至develop分支,并将master分支快速指向该hotfixes分支的最终节点,记录该版本tag

    3. 规范

    3.1分支命名规范

    feature分支: feature-拉取日期(yymmdd)-简述
    例:feature-191201-新增助代通3.0业务
    release分支: release-拉取日期(yymmdd)-版本号
    例:release-191210-3.2.47
    hotfixs分支: hotfixs-拉取日期(yymmdd)-修复后版本号-简述
    例:hotfixs-191211-3.2.47.1-修复绑定终端bug

    3.2节点命名规范

    节点提交(commit、stage)应在提交信息中注明所提交内容的详细描述

    1. .          聚合商户进件需求变更
    2. .          商户名更改为  商户-XXX  >  商户_XXX

    3.3跨仓库提交规范

    当同一动能需要跨仓库开发时,需保证各仓库中创建同样名称的分支进行操作,跨仓库发布应有同样的release分支,注意多个仓库完整地提交代码,防止feature分支在某个库中提前提交或遗漏提交而使其他功能受到影响

    3.4建议

    建议使用独立的Git客户端工具(包括Git bash)维护本地Git仓库以及代码的拉取提交等操作,客户端可以提供较为完善的git操作和更直观的图形化界面,以及更加简单的多仓库管理。

    GitKraken 操作简单直观,免费功能满足正常使用

    SourceTree 完全免费,功能丰富强大

    4. 操作示例

    • 以下提供纯IDEA、IDEA+GitKraken两种操作方式作为参考,其他工具遵循同样规范操作即可

    IDEA集成操作方式

    双击Shift快速搜索Pull操作或菜单栏依次点击VSC >> Git >> Pull打开拉取代码菜单,并选择对应仓库以及分支进行更新

     

     

    双击Shift快速搜索Branches操作或菜单栏依次点击VSC >> Git >> Branches打开分支管理菜单

     

     

     选择对应仓库并切换至develop分支(checkout)

    再次打开分支管理,在对应仓库创建新的feature分支并自动切换至该分支

    在下侧Version Control选项卡中改动文件上右键Commit或双击Shift快速搜索Commit操作或于菜单栏依次点击VSC >> Commit打开提交菜单。选定需要提交的部分并编写完整的提交描述,提交代码(Commit至本地分支,如需共用开发分支可Push至远端)

    开发完毕确定跟进发布,使用前述步骤方法切换至develop分支并更新至最新节点,打开分支管理菜单,选择自己的feature分支进行合并,并处理冲突,确认无误后Push至远端库的develop分支

    至此开发阶段完成,可等待测试环节进入发布release分支进行测试修改,或视情况于develop分支部署开发环境进行预先测试

    IDEA + GitKraken操作方式

    切换至develop分支并拉取最新代码

     在develop最新的节点创建自己的feature分支

    切换到所创建的开发分支,如果需要多人协同开发可将分支推向远端库(push)

    使用IDE进行开发

    所有修改将同步显示在客户端工具中,通过对文件区分暂存(stage)可以实现提交部分代码

    确定需要提交的内容提交至暂存区后,编写详细的提交描述进行提交

    开发完毕确定跟进发布,切换至develop分支,合并自己的feature分支,并处理冲突,确认无误后Push至远端库的develop分支

    至此开发阶段完成,可等待测试环节进入发布release分支进行测试修改,或视情况于develop分支部署开发环境进行预先测试

  • 相关阅读:
    Haproxy基于ACL做访问控制
    K8s之Prometheus监控
    kubernetes之PV及PVC案例
    K8s常见示例
    K8s之Web服务
    Ansible 部署k8s
    K8s之网络通信
    创建资源对象实例
    kubeadm搭建K8s集群
    Go基础之函数递归实现汉诺塔
  • 原文地址:https://www.cnblogs.com/guoziyi/p/13962263.html
Copyright © 2020-2023  润新知