Git本身不参与编译，需通过$(shell git branch --show-current)在Makefile中读取分支名并条件设置CFLAGS；CI中GitHub Actions用${{ github.ref_name }}、Jenkins用env.BRANCH_NAME，均需处理detached HEAD及tag推送等边界情况。
Git 本身不参与编译，也不管理编译器配置；所谓“根据分支名动态调整编译器配置”，本质是靠 git branch --show-current 获取当前分支名，再由构建脚本（Makefile / shell / CI 配置）读取并决策行为。
怎么在 Makefile 中读取当前 Git 分支并切换编译参数
Makefile 没有原生分支感知能力，需用 $(shell git branch --show-current 2>/dev/null) 提取分支名，再用条件判断注入不同宏或路径：
BRANCH := $(shell git branch --show-current 2>/dev/null) ifeq ($(BRANCH),main) CFLAGS += -DNDEBUG -O2 endif ifeq ($(BRANCH),develop) CFLAGS += -DDEBUG_MODE -g -O0 endif ifeq ($(BRANCH),feature/usb) CFLAGS += -DUSB_SUPPORT=1 endif
注意：git branch --show-current 在 detached HEAD 状态下返回空，需额外判断；Makefile 中所有变量展开发生在解析阶段，不能在 recipe 内部动态重读分支。
CI 流水线里如何让 Jenkins 或 GitHub Actions 基于分支设置编译器路径
GitHub Actions 可直接用 ${{ github.head_ref }}（PR 场景）或 ${{ github.ref_name }}（push 场景）；Jenkins Pipeline 则依赖 env.BRANCH_NAME ——但该变量仅在 Multibranch Pipeline 中可靠，在传统 Pipeline 中需手动解析 git rev-parse --abbrev-ref HEAD。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- Jenkins 脚本中避免硬写
if (env.BRANCH_NAME == 'develop') { sh 'export CC=/usr/bin/gcc-12' }，而应通过sh命令导出环境变量，并确保后续make步骤能继承 - GitHub Actions 中不要用
run: echo "CC=/opt/gcc13/bin/gcc" >> $GITHUB_ENV后直接调用gcc，因为默认 PATH 未更新；应显式指定CC: /opt/gcc13/bin/gcc传给构建工具 - 所有 CI 场景下，
git checkout后立即执行git branch --show-current，避免因 shallow clone 导致分支名解析失败
为什么不能把编译器路径写进 .git/config 或 .gitattributes
.git/config 是本地配置，不随仓库同步，无法用于协作或 CI；.gitattributes 控制的是 Git 的文件处理行为（如 line ending、diff driver），**完全不支持执行逻辑或环境变量注入**。试图在里面写 *.c compiler=gcc-12 会静默失效 —— Git 不认识这个字段，也不会触发任何动作。
真正可行的路径只有两条：一是把分支逻辑下沉到构建系统（Make/CMake），二是把分支判断放在 CI 脚本里统一调度。前者更可移植，后者更适合快速验证。
最容易被忽略的一点：分支名带斜杠（如 feature/login）在 Makefile 的 ifeq 中需完整匹配，不能只写 feature；而 CI 系统中 github.ref_name 在 tag 推送时是 refs/tags/v1.2.0，不是分支名 —— 这类边界情况必须单独处理，否则编译器配置会意外 fallback 到默认值。
