跨分支保持连续Build Number问题求助（Fastlane+Crashlytics场景）

我之前也碰到过一模一样的困扰——不同分支各自维护plist里的Build Number，部署时版本号跳来跳去完全不连续。试了几个方案后，终于找到靠谱的解决思路，分享给你：

方案1：用共享文件统一存储Build Number #

把Build Number从plist里抽离出来，放到项目根目录的一个独立文件里，所有分支共用这个文件作为唯一来源：

• 第一步：在项目根目录创建一个.build_number文件，把你当前的Build Number写进去（比如初始值100）
• 第二步：在Fastlane的Fastfile里添加逻辑，读取这个文件的数值、自增、更新plist，再把新值写回文件：

  # 读取共享文件里的当前Build Number
  current_build = File.read(".build_number").to_i
  # 自增生成新的Build Number
  new_build = current_build + 1
  
  # 更新项目Info.plist里的Build Number
  update_info_plist(
    plist_path: "./YourProject/Info.plist", # 替换成你的plist路径
    build_number: new_build.to_s
  )
  
  # 把新的Build Number写回共享文件
  File.write(".build_number", new_build.to_s)
  
  # 可选：提交这个文件到Git，确保其他分支拉取时能拿到最新值
  sh("git add .build_number")
  sh("git commit -m 'Update build number to #{new_build}'")
  

• 注意：每次运行Fastlane前记得拉取最新代码（git pull），避免读取到旧值；如果多人协作，可以加个Git锁或者提醒大家不要手动修改这个文件。

方案2：用Git标签记录Build Number #

利用Git的标签功能来追踪Build Number，不需要额外文件，完全依赖Git本身的版本记录：

• 在Fastfile里添加以下逻辑：

  # 获取所有以build-开头的标签，按版本号排序后取最后一个
  latest_build_tag = sh("git tag | grep 'build-' | sort -V | tail -n 1").chomp
  # 如果是第一次运行，没有标签就初始化为0
  current_build = latest_build_tag.empty? ? 0 : latest_build_tag.split("-").last.to_i
  new_build = current_build + 1
  
  # 更新plist里的Build Number
  update_info_plist(
    plist_path: "./YourProject/Info.plist",
    build_number: new_build.to_s
  )
  
  # 打新的Git标签并推送到远程仓库
  sh("git tag build-#{new_build}")
  sh("git push origin build-#{new_build}")
  

• 这个方法的好处是自带版本回溯功能，你可以通过git tag查看所有历史Build Number，而且所有分支都能获取到最新的标签值。

方案3：借助CI/CD环境存储Build Number #

如果你的项目已经用了CI/CD工具（比如GitHub Actions、GitLab CI），可以把Build Number存在CI的环境变量或专用存储里，避免本地Git操作的冲突：

• 以GitHub Actions为例：
  1. 在仓库的「Settings -> Secrets and variables -> Actions」里添加一个BUILD_NUMBER变量，初始值设为当前的Build Number
  2. 在Fastfile里读取这个变量，自增后更新plist：

     current_build = ENV["BUILD_NUMBER"].to_i
     new_build = current_build + 1
     
     update_info_plist(
       plist_path: "./YourProject/Info.plist",
       build_number: new_build.to_s
     )
     

  3. 在CI脚本里更新BUILD_NUMBER变量（比如用GitHub API或者官方的gh命令），确保下一次运行能拿到最新值

额外注意事项 #

• 并发问题：如果多个开发者或CI任务同时运行Fastlane，可能会出现Build Number重复的情况。可以用Git的lock机制，或者CI环境里的互斥锁来避免。
• 分支同步：不管用哪种方案，都要确保所有分支能及时获取到最新的Build Number来源（共享文件、Git标签、CI变量），避免版本号断层。

内容的提问来源于stack exchange，提问作者Tal Cohen