我们有一组脚本，从历史上看，这些脚本具有不同的名称前缀，具体取决于它们是在生产中使用还是在较低的环境中使用。
我们现在正在切换到 git，如果可能的话，我们希望保留命名约定。假设我签入一个脚本FOO-- 我可以在克隆期间以某种方式告诉 git 将其重命名为磷FOO 或德FOO 依赖于某些命令行参数？
当然，我希望能够自动将任何后续更改提交DFOO到FOO......
git 可以在工作区和存储库之间维护不同的文件名吗？
为什么我们会有这样的命名差异？
这些脚本早在“devops”一词诞生之前就已存在。它们由同样古老（且基于大型机）的调度程序“ESP”执行的作业引用。调度程序中的作业根据是否为“生产”而具有不同的名称 - 这样操作员就可以从作业名称中立即看到要给予其何种程度的关注。
你无需说服我，这，呃，有点“奇怪”——我自己也不会这样设置。以前不会，现在也不会。
但事实已经如此，多年来我对历史古迹产生了一定的兴趣——也许，因为我自己也逐渐成为了其中的一员……
如果 git 没有办法在存储库和工作区之间维护文件名的持久映射，那就这样吧——我们将放弃这种做法。但是，如果有的话，我会使用它...
答案1
不，Git 无法有效处理工作目录中与索引或提交目录中不同的文件名。Git 可以跟踪重命名（使用git mv)，但它会将该重命名应用为上面的分支将复制的更改。
我正在经历类似的事情（将基于 TFVC 团队项目的流程转换为 ADO 中的 git）。
请理解 git 本质上不同于 SVN 之类的版本控制方案，所以答案实际上是否定的。您可以采取一些措施使其按照您描述的方式工作，但是您尝试这样做会违背系统的基本设计。
我强烈建议你研究和采用你正在采用的新技术及其范式，而不是试图将其扭曲成你以前做过的事情。相信我，我知道这很难。
特别研究 git 工作流程。从这里开始了解一些选项。它们确实描述了完成所需任务的最佳方法，无需更改文件名。从主干/集中式工作流程开始，功能分支工作流，扩展为功能分支和发布，然后看看Gitflow，github， 和Gitlabs工作流程。只有在长期维护多个生产版本时，后者才是真正需要的。您确实希望使用专门选择并一致使用的工作流程才能成功使用 Git。
无论如何，要回答您的问题，您可以围绕 git 编写脚本，无论您需要什么 shell（我们使用 git-bash）。话虽如此，我再次警告您不要采用这种方法。它会在您的历史记录中引入渐近线，并阻止您从创建到最终删除记录文件（因为它会在每次通过您的发布管道进行升级时被删除，并创建一个新文件）。
如果您使用或正在转向持续集成/持续交付，考虑一下您可能能够在构建或部署过程的一部分中重命名文件，如果名称仅在部署之后对您很重要。这可能会满足您的需求而不会给您的版本控制带来混乱。