git 常用分支操作

每个公司都有自己的一套git操作模式,但git的各种规范都是相同,下面总结了下常用开发规范操作

分支命名

master - 主干(默认)

一般master位于线上正式服务器的版本,每一次在 master 上的提交或合并都应该伴随着版本号的变更。(这样会更好的记录和版本回退)

master 分支应保证是随时可发布的(可能包含Bug),每个发布的版本应打上 tag,便于回滚。对于有重大 Bug 的版本,应备注,避免回滚到错误的版本。

  • feature/* - 特性分支

    Example: feature/this-is-a-feature-name,名称中间通过 - 分割。

    该分支创建自 master 分支,充分测试后,合并到 master 分支

    开发人员使用的分支,针对每一个功能点 issue 创建一个 feature,一般命名规范为 feature/-,该 feature 下的每次提交格式为 # ,当 feature 开发完毕后 merge 到 develop,并关闭 issue

    实际开发中,可能有些 feature 算不上什么功能上的需求,不太必要有 issue,所以命名时可以没有 

    实际开发中,每个新特征功能都应该进行独立的测试,所以可能需要发布到测试环境中供测试人员进行测试。目前开发流程不方便部署 feature 分支,所以目前不进行feature 的独立测试。

  • develop - 测试分支

    该分支创建自 master 分支,定期与 master 分支同步,featrue 分支 在本 merge 到 develop 后 push 到 github 进行测试。

    测试服运行此分支代码,作为开发环境中的主分支使用,任务是收集各个 feature 分支。

    合并到 develop 分支的代码必须是已经完成开发并在本地进行过充分测试的 feature,即 能够交给测试人员测试的版本

    因该分支上可能包含多个 feature,且 多个 feature 可能处于不同阶段,所以该分支一般不合并的到 master

  • release/* - 预发布版本

    预发布版本,当 develop 收集够了做一次版本发布所需的代码,就 checkout -b 出一个 release 分支,作为上线前的最后测试,除了 bugfix 外不接受任何提交。确认发布后分别 merge 到 master 和 develop

    如果能够明确定义版本,且明确定义 某版本包含哪些功能的情况下,可在 某版本 定义的功能全部开发完毕之后,创建 release 分支,进行 master + release 灰度部署。

  • hotfix/*

    紧急修复分支,当 master 上出现 bug 需要修复时,基于 master 创建 hotfix 分支,修复完成后分别 merge 到 master 和 develop

    开发分支中可能存在Bug,直接修改就可以了,无须创建分支修复Bug,所以,hotfix/* 只针对发布的版本。

 

标签命名

  • 语义化版本 2.0.0
  • 软件版本周期
  • 版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  • 主版本号:当你做了不兼容的 API 修改,通常是进行了大规模的重新设计,重新定义了 API。
  • 次版本号:当你做了向下兼容的功能性新增,通常对应发布了 feature/*
  • 修订号:当你做了向下兼容的问题修正。通常对应发布了 hotfix/*
  • 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

    Example:

    Commit

    Format

    [()]: 
    // 空一行
    []
    

    Format with GitEmoji

    :emoji1: :emoji2: 不超过 50 个字的摘要,首字母大写,使用祈使语气,句末不要加句号
    
    提交信息主体
    
    引用相关 issue 或 PR 编号 <#110>
    
    # Ref https://github.com/thoughtbot/dotfiles/blob/master/gitmessage
    #
    # 50-character subject line
    #
    # 72-character wrapped longer description. This should answer:
    #
    # * Why was this change necessary?
    # * How does it address the problem?
    # * Are there any side effects?
    #
    # Include a link to the ticket, if any.
    #
    # Add co-authors if you worked on this code with others:
    #
    # Co-authored-by: Full Name 
    # Co-authored-by: Full Name 
    
  • type:

    • feat - 新功能
    • fix - 修复bug
    • br - 此项特别针对bug号,用于向测试反馈bug列表的bug修改情况
    • test - 测试
    • docs - 文档()
    • style - 格式(不影响代码运行的变动)
    • refactor - 重构(即不是新增功能,也不是修改bug的代码变动)
    • chore - 构建过程或辅助工具的变动
    • revert - 执行了 git-revert
  • scope

    scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。

  • Develop -> Deploy

  • 创建分支

    git checkout feature/xxx

    注意:feature/xxx 应基于 master,所以 此时命令应在 master 分支上进行

  • 修改

    git add

    git commit

  • 推送到远程

    git push

  • 同步 develop 分支,自动部署 develop 分支部署到 demo 服务器

    git branch -f develop feature/xxx

    git push -f origin develop

    自定义快捷命令,放到 ~/.bashrc ~/.zshrc 中即可

    function gitdd () {
    	echo 'deploy current branch to demo'
    	git branch -f develop HEAD 
    	git push -f origin develop
    }

    usage:

    gitdd

    以上命令在当前分支 feature/xxx 下进行,不需要切换分支

  • Pull Request

    请求将 feature/xxx 合并到 master 上

  • 部署正式服

    1. 将分支 切回 master

      git checkout master

      此时 feature/xxx 已经完成任务,可以删除

    2. · 打 Tag,部署正式服 服务自动处理

      • git tag vx.x.x
      • git push origin vx.x.x
    3. 创建 release/vx.x.x,部署正式服

      • git branch release/vx.x.x
      • git push origin release/vx.x.x

你可能感兴趣的:(git,git,github,规范,分支)