如何让loop.sh及调用的task.sh可靠使用Git main分支版本？

问题1：只要在main分支运行loop.sh，task.sh就会自动使用main版本，是否属实？ #

不属实。Git分支切换会直接替换工作区的文件内容——当你切换到new-feature分支后，工作区的task.sh会被替换为该分支的版本。而loop.sh调用./task.sh时，读取的是当前工作区的文件，和loop.sh自身所属的分支无关。哪怕loop.sh是从main分支启动的，只要你后续切换了分支，它调用的就是切换后分支的task.sh。

问题2：在loop.sh中加入git checkout main是错误的，是否正确？原因是什么？ #

正确，这种做法存在严重问题：

• 干扰本地开发：如果你正在new-feature分支开发（有未提交的修改），git checkout main要么会因为冲突失败（导致loop.sh报错终止），要么会强制覆盖你的未提交修改（造成代码丢失）。
• 破坏工作区状态：loop.sh运行在独立的screen进程中，执行git checkout main会全局改变仓库的分支状态，导致你在主终端的开发环境被迫切换到main，打断正常工作流程。
• 不可控的分支冲突：如果有多个类似的定时脚本同时执行分支切换，会引发Git分支状态的混乱，增加调试难度。

问题3：git show main:task.sh | bash能否直接替换原有的./task.sh？原脚本需要接收参数，且我有时会处理脚本的管道输出。 #

可以，但需要调整写法来支持参数传递和避免标准输入冲突：

• 直接用管道git show main:task.sh | bash的问题：无法传递参数给task.sh，且如果task.sh需要读取标准输入（比如处理用户输入或其他管道数据），会被git show的输出占用，导致逻辑异常。
• 改进写法：使用进程替换，将git show输出的main分支版本作为临时脚本文件传递给bash，同时支持参数传递：

  bash <(git show main:task.sh) arg1 arg2 arg3
  

  这种写法下：
  • 参数arg1、arg2会正常传递给task.sh（可通过$1、$2读取）
  • task.sh的标准输入不会被占用，你可以正常处理其他管道输出或用户输入
  • 注意：如果task.sh中引用了仓库内的其他文件（比如./config.ini），这些文件仍会读取当前工作区的版本。如果需要这些文件也用main分支版本，需要同样用git show main:config.ini的方式读取，或者采用更彻底的隔离方案。

更稳妥的长期解决方案：隔离运行环境 #

最可靠的方式是将main分支的代码单独检出到一个独立目录，在该目录中运行loop.sh，彻底与开发环境隔离：

1. 创建独立的main分支工作目录：

   git clone /path/to/your/repo repo-main
   cd repo-main
   git checkout main
   

2. 在该目录中启动loop.sh：

   screen -S loop ./loop.sh
   

这样无论你在原仓库的new-feature分支如何修改代码，loop.sh调用的始终是独立目录中main分支的稳定版本，完全避免了开发环境对运行环境的干扰。

内容的提问来源于stack exchange，提问作者Petr Doležal