如何轻松删除多个文件，而无需手动输入所有文件的完整路径git rm？我有很多修改过的文件要保留，因此也无法删除所有修改过的文件。
并且是否可以在不手动输入的情况下恢复多个文件的更改git checkout -- /path/to/file？
问问题
29858 次
11 回答
44
您可以给git rm.
例如
git rm *.c
或者您可以在另一个文件中写下所有文件的名称，例如filesToRemove.txt：
path/to/file.c
path/to/another/file2.c
path/to/some/other/file3.c
您可以自动执行此操作：
find . -name '*.c' > filesToRemove.txt
打开文件并查看名称（以确保一切正常）。
然后：
cat filesToRemove.txt | xargs git rm
或者：
for i in `cat filesToRemove.txt`; do git rm $i; done
检查手册页以xargs获取更多选项（尤其是文件太多时）。
于 2012-03-02T07:16:18.763 回答
11
只需使用任何其他方法（Explorer 等）删除它们，然后运行git add -A. 至于还原多个文件，您也可以签出一个目录。
于 2012-03-02T07:13:37.817 回答
4
我发现git rm' 处理通配符很烦人。Find 可以在一行中完成：
find . -name '*.c' -exec git rm {} \;
这{}是文件名将被替换的地方。最棒的find是它可以过滤大量的文件属性，而不仅仅是名称。
于 2016-01-20T00:25:43.850 回答
2
要一次删除多个文件，您可能需要在此处查看答案
您可以删除不需要的文件并运行以下命令：git rm $(git ls-files --deleted)
于 2015-06-19T21:06:11.577 回答
2
简单的方法：
- 在文件资源管理器中删除文件
- 用来
git ls-files --deleted | xargs git add上演它们。推送后，它们将在遥控器中删除。
Git方式：参考@CpILL所说的（https://stackoverflow.com/a/34889424/6538751）使用
find . -name 'DeleteMe*.cs' -exec git rm {} \;
您可以使用通配符。
于 2020-07-30T23:11:38.960 回答
1
在 POSIX 系统上，您可以创建一个与所有所需文件匹配的 shell glob，您可以简单地将其传递给git rmand git checkout --。在 Windows 上， cmd.exe 和 PowerShell 不包括通配符并将其分配给应用程序（根据我的阅读，git 不会为文件执行此操作）。您需要使用 Windows 命令或脚本来准备文件列表并将其适当地通过管道传输到您的 git 命令以获得类似的效果。
将文件列表传递给 shell 命令的任何策略都适用于接受文件路径的 git 命令。
于 2012-03-02T07:10:46.823 回答
1
在 Windows 10 上，使用 Git Bash，从.gitignore文件结构中的位置开始。
git rm -r --cached some_directory/
我只是用它来递归地忽略整个目录。这是我的.gitignore文件中的内容：
# Use .gitignore to ignore a directory and its contents #
/some_directory/
于 2016-08-17T17:12:26.270 回答
0
您还可以查看Cygwin，因为它在 Windows 上提供了许多 Unix/Linux/*BSD 功能。Cygwin 包括一个 Bash shell 和 find(1)，以及上面提到的其他工具。（我通常在 Windows 7 上一次启动 2-4 个 Cygwin mintty 终端，因为我觉得 Cygwin 很方便。）
于 2012-10-02T15:25:49.017 回答
0
您只需使用
find . -name '*.DS_Store' | xargs git rm
删除许多匹配通配符的文件。
于 2019-03-01T02:38:27.473 回答
0
或者你可以在另一个文件中写下所有文件的名称，比如
filesToRemove.txt
这是 Git 2.26（2020 年第二季度）的好方法，因为 " git rm" 和 " git stash" 学习了新的 " --pathspec-from-file" 选项。
所以不再有for i incat filesToRemove.txt; do git rm $i; done
一个简单git rm --pathspec-from-file=filesToRemove.txt的就够了。
请参阅Alexandr Miloslavskiy ( ) 的提交 8a98758、提交 8c3713c、提交 3f3d806、提交 b229091、提交 0093abc、提交 2b7460d、提交 5f393dc（2020 年 2 月 17 日）和提交 6a7aca6（2020 年 1 月 16 日）。（由Junio C Hamano 合并 -- --在提交 9b7f726中，2020 年 3 月 9 日）SyntevoAlex
gitster
rm: 支持 --pathspec-from-file 选项签字人：亚历山大·米洛斯拉夫斯基
为简单起见做出的决定：
不允许在 args 和 file 中传递 pathspec。
块需要调整
if (!argc)：此代码实际上意味着“pathspec 不存在”。
以前，pathspec 只能来自命令行参数，因此测试 forargc是测试 pathspec 是否存在的有效方法。但这不再适用于--pathspec-from-file.在整个
--pathspec-from-file故事中，我试图让它的行为非常接近于在命令行上给出 pathspec，这样从一个切换到另一个不会带来任何意外。但是，在空的情况下向用户抛出使用
--pathspec-from-file会令人困惑，因为“使用”（即 argc/argv 数组）没有任何问题。另一方面，在旧案例中抛出用法也让我感觉不好。虽然这不是一个难题，但我（作为用户）从不喜欢将我的命令行与“用法”进行比较的体验，试图找出不同之处。由于已经知道错误是什么，因此将特定错误提供给用户感觉要好得多。
从commit 7612a1ef ("
git-rm:honor-nflag" 2006-06-09, git v1.4.0)来看，在这种情况下显示使用似乎并不重要（补丁是为了避免segfault），它不适合了解其他命令如何对空路径规范做出反应（例如git add，参见自定义消息）。因此，我决定在这两种情况下都显示新的错误文本。
为了尽早继续测试错误，我移动parse_pathspec()得更高。现在它发生在read_cache()/hold_locked_index()/之前setup_work_tree()，这不会引起任何问题。
于 2020-03-10T17:03:39.043 回答