Git checkout 到外部工作树并删除已删除的文件

Question

我们想使用 Git 在我们的网络服务器上部署代码。因此，我们在生产服务器上初始化了一个裸存储库。每当我们发布新版本时，我们都会对网站的 DocumentRoot 执行 git checkout:

git --work-tree=/path/to/webroot/ checkout -f master

在 webroot 的子目录中，有几个文件不被 Git 跟踪(缓存文件、用户上传的文件等)。在执行 checkout 时，Git 当然不能删除这些(到目前为止这部分工作正常)。

但是，Git 也不会删除以前跟踪过但同时已被删除的文件(例如，由于不再需要，它们在开发过程中被删除)。这些文件目前在 checkout 过程中幸存下来，导致“死”文件的数量稳步增加。有没有办法让 Git 在执行 checkout 时删除这些文件？

编辑 - 重现步骤:

# create dirs and repos
cd /base/path
mkdir repo.git
mkdir target
cd repo.git && git init

# create, add and commit two files
touch test1.txt
touch test2.txt
git add test1.txt test2.txt
git commit -m testcommit

# checkout to target directory
git --work-tree=../target checkout master -f
# target directory now contains both files

# remove one file from file system and git repo, commit
rm test2.txt
git rm test2.txt
git commit -m deletecommit

# checkout to target again
git --work-tree=../target checkout master -f
# target still contains both files

Answer 1

However, Git also does not delete files which were previously tracked, but have been removed in the meantime

是的，使用 Git 2.22(2019 年第二季度)和 git checkout --overlay ，确实如此。
“git checkout --no-overlay ”可用于触发一种新模式，用于检查树结构之外的路径，允许与当前索引和工作树中的路径规范匹配但不在树结构中的路径。

参见 commit e92aa0e (2019 年 2 月 4 日)，commit 1495ff7 , commit 091e04b (2019 年 1 月 8 日)，以及 commit b7033e7 , commit 5160fa0 , commit 6fdc205 , commit 536ec18 , commit b702dd1 , commit a0cc584 (2018 年 12 月 20 日)Thomas Gummerer ( tgummerer ) .
推荐人:Jonathan Nieder ( artagnon ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 7d0c1f4 ，2019 年 3 月 7 日)}

checkout: introduce --{,no-}overlay option

Currently 'git checkout' is defined as an overlay operation, whichmeans that if in 'git checkout <tree-ish> -- [<pathspec>]' we have anentry in the index that matches <pathspec>, but that doesn't exist in<tree-ish>, that entry will not be removed from the index or theworking tree.

Introduce a new --{,no-}overlay option, which allows using 'git checkout' in non-overlay mode, thus removing files from the working tree if they do not exist in <tree-ish> but match <pathspec>.

Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already worksthis way, so no changes are needed for the patch mode.
We disallow 'git checkout --overlay -p' to avoid confusing users who would expectto be able to force overlay mode in 'git checkout -p' this way.

Untracked files are not affected by this change, so 'git checkout --no-overlay HEAD -- untracked' will not remove untracked from the working tree.
This is so e.g. 'git checkout --no-overlay HEAD -- dir/' doesn't delete all untracked files in dir/, but rather just resets the state of files that are known to git.

你有一个 new git config setting :

checkout.overlayMode:

In the default overlay mode, git checkout never removes files from the index or the working tree.
When setting checkout.overlayMode to false, files that appear in the index and working tree, but not in <tree-ish> are removed, to make them match <tree-ish> exactly.

---

带有通配符路径规范的“`git restore/checkout --no-overlay”错误地删除了子目录中的匹配路径，该问题已在 Git 2.29(2020 年第 4 季度)中得到纠正。

参见 commit bfda204 (2020 年 8 月 22 日)René Scharfe ( rscharfe ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit c57afd7 ，2020 年 8 月 31 日)}

checkout, restore: make pathspec recursive

^{Reported-by: Sergii Shkarnikov
Initial-test-by: Sergii Shkarnikov
Helped-by: Jeff King
Signed-off-by: René Scharfe}

The pathspec given to git checkout and git restore^(man) and is used with both tree_entry_interesting (via read_tree_recursive) and match_pathspec (via ce_path_match).

The latter effectively only supports recursive matching regardless of the value of the pathspec flag "recursive", which is unset here.

That causes different match results for pathspecs with wildcards, and can lead checkout and restore in no-overlay mode to remove entries instead of modifying them.

Enable recursive matching for both checkout and restore to make matching consistent.

Setting the flag in checkout_main() technically also affects git switch^(man), but since that command doesn't accept pathspecs at all this has no actual consequence.