others-软件版本控制

分类于

others-软件版本控制

客户端分支开发流程

竖线代表版本时间线. B 为当前线上版本, 假设线上版本出了 bug. master 为开发分支, rls_test_gp 为线上版本的测试分支, rls_final_gp 为线上正式分支. ( rls_final_gp 是 release_final_googleplay 的简称)

建议本地有 2 个工程以上, 一个 master 分支, 一个 rls_test_gp 分支, 这样就不用来回切换

流程:

  1. 本地切到 rls_test_gp 分支 (最好 pull 远端对齐代码) , 在 B版本 修改线上出的 bug,
  2. 修改测试完没问题后, 本地 commit 一下, 变为 C版本
  3. 将本地 C版本 push 到远端, 使远端变为 C版本
  4. 提一个 merge request, (参考: [远端 merge 代码](#远端 merge 代码)) 把远端 rls_test_gp 分支的代码 合并到 远端 rls_final_gp 分支上, 使 远端 rls_final_gp 分支变为 C版本
  5. 在 打包机 本地 rls_final_gp 分支的基础上, 把 远端 rls_final_gp 分支的代码 pull 下来 ( pull 之前最好 reset all 一下),
    1. 检测 rls_final_gp 分支最后 patch 或 打包 时间 到 现在 是否有人修改引擎. 参考: 检测是否修改引擎
    2. 打个patch. 至此, 修复 线上 bug 结束.
  6. 然后把修的 bug 重 远端 rls_test_gp 分支合并到你的 master 分支上. 因为 master 是一直在开发中的, A版本 肯定会 高于 修前的 B版本, 如果 A-B 之间 和 B-C 之间 有修改到同一块地方, 那么肯定是会冲突的, 这个不可避免.
    1. 本地切到 master 分支, 把修改的 commit 一下,
    2. 然后 pull 远端 rls_test_gp 分支. 有冲突就解决冲突. 这个 pull 操作会自动 merge, 所以就不需要在 web端 (远端)上 提一个 merge request 把 rls_test_gp 和到 master 上, 因为有冲突是合不了的.
  7. 本地 master 分支 push 到 远端 master 分支上. 至此, 合并到 master 分支结束.

绝对不能执行的操作: 本地 rls_test_gp 分支 pull 远端 master 分支后 再 push 到 远端 master 分支. 这样虽然可以把修 bug 的版本合到 master 开发分支上, 但是 pull 会导致 master 开发分支的东西合到 rls_test_gp, 这是绝对不允许的.

如果不是开发新功能, 只是修修 bug, 直接在 rls_test_gp 分支上进行

开发新功能就必须在 master 分支上进行.

有修改到底层代码必须要清楚是否会影响到线上版本. 提交日志一定要注明 是否 修改引擎

远端 merge 代码

  1. 创建 合并请求

  2. 左边是版本 落后 的分支, 右边是版本 较新 的分支

    合并内容简要填写一下, 就 创建合并请求

  3. 点击 合并请求, 执行合并. done

本地 merge 代码

将 分支a 合到 分支b

  1. 切到 分支b

  2. 直接 pull 远端分支a

    或者 本地分支a 与 远端分支a 相同, 可以直接 merge 分支a -> 当前分支.

  3. 将 分支b push 到 远端分支b

检测是否修改引擎

工具逻辑由 python 脚本实现, 然后在集成到 unity 中可视化.

  1. 每次 打包 or 打patch 都会有记录, 在 /Users/its/rummy_android_rls/patch 目录下, 一般最后一个文件 z_xxx.json, 文件名上有时间, 里面也记录 "time": "20190831_224455"

  2. 把时间按格式填入 开始时间, 点击 检测. (需要环境有 python3)

线上紧急 bug 修复

  1. 直接从 rls_final_gp 创建一个新分支如: yx_final_gp_login (名字_final_渠道_bug), 修复测试好 merge 到 rls_final_gp 分支
  2. 从 rls_final_gp 打patch. 至此, 线上修复ok.
  3. 然后把 yx_final_gp_login 分支 merge 其他开发分支.

打线上调试包

  1. 本地切到 rls_final_gp 分支

  2. 设置 参数 打包

    1. 快捷设置设置对应渠道的参数
    2. 最后一次 patch 的版本号
    3. lua 明文模式, 方便真机调 lua
    4. 脚本运行为 mono 模式, 打包 apk 快
    5. 不打 aab 包
    6. 日志等级设置为 debug
    7. 打包

打 patch 流程

  1. 切到 rls_final_gp 分支, 打一个 内网 (热更, 拉配置 url 也是内网) debug apk 包, 对齐线上版本
  2. 切到 rls_test_gp, 打一个 patch,
  3. debug apk 测试 patch, 测试内容, 没问题后. 把 rls_test_gp 分支 合并到 rls_final_gp 分支, rls_final_gp 分支打 patch 给线上热更.

tag 格式

每次打完 patch/app 都需要打一个 tag, 方便在 时间线 上显示, 也方便后面快速回滚到上一个 稳定版本

tag 格式: rls-<app|patch>-<v1|v2|vn>-<渠道7版本or其他>, 例如:

  • rls-app-v1-0.9.1.1
    渠道: 1011, 1012
    描述: 修复 bug

  • rls-patch-v2-0.9.1.1
    渠道: all
    描述: 换皮

查找所有 tag 及 sha1

1
2
3
4
$ git log  --decorate --tags --no-walk --pretty=format:"myflag: %H @ %S @ %an @ %ai @ %s"
myflag: e232d5fdd4a6710ced07887140dfed27f7153e31 @ rls-patch-v1-0.9.1.1 @ 陈为博 @ 2020-03-24 21:09:35 +0800 @ 描述: 点击手机返回
键，撤销Paytm支付
myflag: c5505467f5910363806fbdefcae4a608efab0734 @ rls-app-v1-0.9.0.1 @ yangxuan @ 2020-03-06 16:23:51 +0800 @ 描述: 打包工具

需要用 tag 的情况

  1. 修改底层代码.
    • 增加功能: feature-xxx
    • 修复 bug: fixed-xxx
  2. 打包, 打 patch
    • 打包: rls-app-v1-0.9.1.1
    • 打 patch: rls-patch-v2-0.9.1.1
  3. 其他, 比如 独立 res 等操作需要标记的提交节点, 也需要打点 tag
    • 命名: other-xxx

附: