<p>应使用 git rev-parse --abbrev-ref HEAD 获取纯净分支名，再通过 case 判断分支类型执行对应构建逻辑：develop 打 dev-tag 并生成 -dev 后缀包；test 跳过单元测试、仅 lint+assembleDebug 且包名加 -test；release/* 启用 ProGuard、签名并上传；其他分支仅 assembleDebug。</p>
如何用 shell 脚本识别当前 Git 分支并触发对应构建逻辑
脚本必须能稳定读取当前分支名，不能依赖 git branch 的星号标记（输出不稳定），也不能硬编码分支列表。正确做法是用 git rev-parse --abbrev-ref HEAD 获取纯净分支名，再用 case 或 if 判断分支类型。
-
develop分支走预发布流程：打dev-前缀的 tag，生成带-dev后缀的 APK/IPA -
test分支走冒烟测试流程：跳过单元测试，只做 lint + assembleDebug，包名后缀加-test -
release/*（如release/1.2.0）走正式构建：启用 ProGuard、签名、上传到蒲公英/Fir.im - 其他分支默认只执行
./gradlew assembleDebug，不发包
Gradle 构建参数如何随分支动态注入
Android/iOS 构建时，版本名、包名、API 地址等常需按分支区分。直接改 build.gradle 不现实，应通过 --project-prop 传参，再在 Gradle 中用 project.findProperty("env") ?: "dev" 读取。
Git Pushing
下载
使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。
- 在 shell 脚本中调用：
./gradlew assembleRelease -Penv=test -PversionCode=102 - Gradle 里用
android.defaultConfig.applicationId = "com.example.${project.findProperty("env")}"动态设包名 - 避免把敏感配置（如签名密钥路径）写进脚本，统一从
~/.gradle/gradle.properties读取 -
-P参数无法覆盖ext里已赋值的变量，务必在ext初始化前读取project.findProperty
编译产物自动归类与分发失败时如何快速定位
不同分支产出的包必须严格隔离存放，否则容易发错包。建议按
dist/<branch>/<timestamp>/结构组织目录，且每次构建前清空同分支旧目录。
- 分发失败常见原因：蒲公英 API token 过期、
curl未安装、APK 路径含空格（要用"${apk_path}"引号包裹） - 上传前务必校验文件存在且非零大小：
[ -s "${apk_path}" ] || { echo "APK missing or empty"; exit 1; } - 蒲公英上传返回 JSON，用
jq '.code == 0'判断成功，别只看 HTTP 状态码（它常返回 200 即使业务失败） - 失败时保留完整日志（含
git log -1和git diff --stat），方便回溯是否因某次提交引入构建异常
为什么不能直接用 GitHub Actions / GitLab CI 替代本地脚本
CI 环境适合标准化发布，但多分支一键编译的核心诉求是“开发机上快速验证”，比如测试同学临时拉个 feature/login-v2 分支想立刻装包试用——CI 要 push 触发、排队、下载依赖，太重。
- 本地脚本可跳过 CI 的 checkout + cache 拉取环节，直接复用当前工作区状态
- 调试时能交互式输入版本号、选择是否签名，CI 流水线做不到这点
- 但要注意：本地脚本不能替代 CI 的代码扫描和合规检查，上线前仍需走 CI 流水线兜底
- 如果团队强制要求所有包必须经 CI 发出，那本地脚本只保留构建能力，分发逻辑直接删掉
test 分支忘了关 Crashlytics 初始化，结果测试包上报了大量 fake crash。这类问题不会报错，只能靠人工核对 build.gradle 差异。 
