我不认为 Git 提交可以记录像“停止跟踪此文件，但不删除它”这样的意图。
实现这样的意图将需要在 Git 外部对任何合并（或变基）删除文件的提交的存储库进行干预。
保存副本、应用删除、恢复
最简单的方法可能是告诉下游用户保存文件的副本，提取删除内容，然后恢复文件。
如果他们通过 rebase 拉取并对文件进行“携带”修改，则会发生冲突。要解决此类冲突，请使用git rm foo.conf && git rebase --continue（如果冲突的提交除了已删除的文件之外还有其他更改）或git rebase --skip（如果冲突的提交仅更改为已删除的文件）。
拉取删除文件的提交后将文件恢复为未跟踪状态
如果他们已经拉取了您的删除提交，他们仍然可以使用以下命令恢复文件的先前版本git show http://www.kernel.org/pub/software/scm/git/docs/git-show.html:
git show @{1}:foo.conf >foo.conf
Or with git 结账 http://git-scm.com/docs/git-checkout（根据 William Pursell 的评论；但请记住将其从索引中重新删除！）：
git checkout @{1} -- foo.conf && git rm --cached foo.conf
如果他们在拉出您的删除后采取了其他操作（或者他们正在将 rebase 拉入分离的 HEAD），那么他们可能需要除@{1}。他们可以使用git log -g在他们删除您的删除之前找到提交。
在评论中，您提到要“取消跟踪但保留”的文件是运行软件所需的某种配置文件（直接从存储库中）。
将文件保留为“默认”并手动/自动激活它
如果继续在存储库中维护配置文件的内容并非完全不可接受，您也许可以将跟踪文件重命名为（例如）foo.conf to foo.conf.default然后指导您的用户cp foo.conf.default foo.conf应用重命名提交后。
或者，如果用户已经使用存储库的某些现有部分（例如脚本或由存储库中的内容配置的其他程序（例如Makefile或类似））要启动/部署您的软件，您可以将默认机制合并到启动/部署过程中：
test -f foo.conf || test -f foo.conf.default &&
cp foo.conf.default foo.conf
有了这样的默认机制，用户应该能够拉取重命名的提交foo.conf to foo.conf.default无需做任何额外的工作。
此外，如果您将来进行其他安装/存储库，您还可以避免手动复制配置文件。
重写历史无论如何都需要手动干预......
如果维护存储库中的内容是不可接受的，那么您可能希望使用类似的方法将其从历史记录中完全消除git filter-branch --index-filter … http://git-scm.com/docs/git-filter-branch。
这相当于重写历史记录，这将需要对每个分支/存储库进行手动干预（请参阅git 变基 manpage http://git-scm.com/docs/git-rebase）。
配置文件所需的特殊处理只是从重写中恢复时必须执行的另一个步骤：
- 保存配置文件的副本。
- 从重写中恢复。
- 恢复配置文件。
忽略它以防止复发
无论您使用什么方法，您可能都希望将配置文件名包含在.gitignore文件存储在存储库中，这样任何人都不会无意中git add foo.conf再次（这是可能的，但需要-f/--force）。
如果您有多个配置文件，您可能会考虑将它们全部“移动”到一个目录中并忽略整个事情（通过“移动”我的意思是更改程序期望找到其配置文件的位置，并让用户（或启动/部署机制）将文件复制/移动到新位置；您显然不希望git mv将文件放入您将忽略的目录中）。
