git-checkout 是否会在发生致命错误时保留 'half-done' 工作树更改？
Does git-checkout keep 'half-done' worktree changes on fatal error?
jordan zu$ git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.
nothing to commit, working tree clean
jordan zu$ git checkout master
error: unable to unlink old 'api_rest/vendor/....php': Permission denied
fatal: cannot create directory at 'api_rest/vendor/...php': Permission denied
jordan zu$ git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
---- 100's of deleted/modified files ---
jordan zu$ git branch
master
* origin/features
^^^ still on origin/features; but index is now changed!
所以，我在 'features' b运行ch 上做了 'git checkout master'，但失败了。失败后，我 运行 'git status'，现在我的索引中充满了更改和未跟踪的文件。所以，这就是我认为发生的事情：git checkout 尽可能地修改工作树，但是一旦遇到错误，它就会退出，并且不会更新 HEAD。它没有将工作树恢复到 运行 之前，而是直接退出。
我的想法对吗？是这样吗？
子问题；部分问题是当我启动我的 docker 服务时，它们修改了一些工作树并留下了 'root' 拥有的目录和文件，这就是 git 结帐遇到的地方问题。有没有标准的方法来处理这种情况？我能以某种方式将 docker 用户映射到工作树的所有者吗？
感谢您的帮助。
git checkout got as far as it could with modifying the worktree, but once it hit an error, it quit, and didn't update HEAD. Instead of reverting the worktree to before it was ran, it just quits.
我认为确实是这样。
git status 显示：
- 索引文件与当前 HEAD 提交之间存在差异的路径，
- 工作树和索引文件之间存在差异的路径，
- 和工作树中未被 Git
跟踪的路径
如果 HEAD 仍然作为功能，而索引和工作树开始反映 master，您会看到所有这些差异。
顺便说一句，使用 git switch master 将是 modern equivalent of git checkout（切换分支时，因此 switch 命令
part of the problem is that when I start my docker services, they modify some of the worktree and leave directories and files that are owned by 'root', and this is where git checkout runs into problems.
Can I map the docker user to the owner of the worktree somehow?
是的，你可以 Isolate containers with a user namespace
The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users.
For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host.
The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.
总则：
About remapping and subordinate user and group IDs
The remapping itself is handled by two files: /etc/subuid and /etc/subgid.
Each file works the same, but one is concerned with the user ID range, and the other with the group ID range.
Consider the following entry in /etc/subuid:
testuser:231072:65536
This means that testuser is assigned a subordinate user ID range of 231072 and the next 65536 integers in sequence.
UID 231072 is mapped within the namespace (within the container, in this case) as UID 0 (root).UID 231073 is mapped as UID 1, and so forth.
If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, which does not even map to a real user.
This means the process has no privileges on the host system at all.
在您的情况下，这意味着容器内的用户 root 可以作为您当前的用户帐户在容器外写入文件 uid/gid。
我通常问的是：
cat /etc/docker/daemon.json
{
"data-root": "/project/docker-root",
"storage-driver": "overlay2",
"userns-remap": "myUserApp1:myGroup" =====
}
sysctl -w user.max_user_namespaces=15000
systemctl restart docker
systemctl status docker
cat /proc/sys/user/max_user_namespaces
（关于 user.max_user_namespaces，参见“Docker error process_linux.go:319: getting the final child's pid from pipe caused "EOF": unknown", and moby/moby issue 40835）
有：
cat /etc/subuid
myUserApp1:44581:65536
cat /etc/subgid
myGroup:14220:65536
（假设当前用户帐户 myUserApp1:MyGroup 具有 uuid/guid 44581:14220）
有时（例如 Docker JBoss/wildfly 图像，默认情况下以 1000:1000 运行），我必须使用 43581（而不是 44581）请求 /etc/subuid，因为这样，容器内的用户1000映射到容器外的44581（43581+1000）。
大缺点：这意味着您只能将一个个内部容器用户映射到一个个外部主机用户。
如果您有另一个使用 1000:1000 运行的容器，它将映射到相同的 myUserApp1，即使您可能有另一个服务帐户 myUserApp2 用于第二个容器持久数据。
jordan zu$ git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.
nothing to commit, working tree clean
jordan zu$ git checkout master
error: unable to unlink old 'api_rest/vendor/....php': Permission denied
fatal: cannot create directory at 'api_rest/vendor/...php': Permission denied
jordan zu$ git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
---- 100's of deleted/modified files ---
jordan zu$ git branch
master
* origin/features
^^^ still on origin/features; but index is now changed!
所以，我在 'features' b运行ch 上做了 'git checkout master'，但失败了。失败后，我 运行 'git status'，现在我的索引中充满了更改和未跟踪的文件。所以，这就是我认为发生的事情：git checkout 尽可能地修改工作树，但是一旦遇到错误，它就会退出，并且不会更新 HEAD。它没有将工作树恢复到 运行 之前，而是直接退出。
我的想法对吗？是这样吗？
子问题；部分问题是当我启动我的 docker 服务时，它们修改了一些工作树并留下了 'root' 拥有的目录和文件，这就是 git 结帐遇到的地方问题。有没有标准的方法来处理这种情况？我能以某种方式将 docker 用户映射到工作树的所有者吗？
感谢您的帮助。
git checkoutgot as far as it could with modifying the worktree, but once it hit an error, it quit, and didn't update HEAD. Instead of reverting the worktree to before it was ran, it just quits.
我认为确实是这样。
git status 显示：
- 索引文件与当前 HEAD 提交之间存在差异的路径，
- 工作树和索引文件之间存在差异的路径，
- 和工作树中未被 Git 跟踪的路径
如果 HEAD 仍然作为功能，而索引和工作树开始反映 master，您会看到所有这些差异。
顺便说一句，使用 git switch master 将是 modern equivalent of git checkout（切换分支时，因此 switch 命令
part of the problem is that when I start my docker services, they modify some of the worktree and leave directories and files that are owned by 'root', and this is where git checkout runs into problems.
Can I map the docker user to the owner of the worktree somehow?
是的，你可以 Isolate containers with a user namespace
The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users.
For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host.
The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.
总则：
About remapping and subordinate user and group IDs
The remapping itself is handled by two files:
/etc/subuidand/etc/subgid.
Each file works the same, but one is concerned with the user ID range, and the other with the group ID range.Consider the following entry in
/etc/subuid:testuser:231072:65536This means that
testuseris assigned a subordinate user ID range of231072and the next 65536 integers in sequence.
UID 231072is mapped within the namespace (within the container, in this case) asUID 0(root).UID 231073is mapped asUID 1, and so forth.If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, which does not even map to a real user.
This means the process has no privileges on the host system at all.
在您的情况下，这意味着容器内的用户 root 可以作为您当前的用户帐户在容器外写入文件 uid/gid。
我通常问的是：
cat /etc/docker/daemon.json
{
"data-root": "/project/docker-root",
"storage-driver": "overlay2",
"userns-remap": "myUserApp1:myGroup" =====
}
sysctl -w user.max_user_namespaces=15000
systemctl restart docker
systemctl status docker
cat /proc/sys/user/max_user_namespaces
（关于 user.max_user_namespaces，参见“Docker error process_linux.go:319: getting the final child's pid from pipe caused "EOF": unknown", and moby/moby issue 40835）
有：
cat /etc/subuid
myUserApp1:44581:65536
cat /etc/subgid
myGroup:14220:65536
（假设当前用户帐户 myUserApp1:MyGroup 具有 uuid/guid 44581:14220）
有时（例如 Docker JBoss/wildfly 图像，默认情况下以 1000:1000 运行），我必须使用 43581（而不是 44581）请求 /etc/subuid，因为这样，容器内的用户1000映射到容器外的44581（43581+1000）。
大缺点：这意味着您只能将一个个内部容器用户映射到一个个外部主机用户。
如果您有另一个使用 1000:1000 运行的容器，它将映射到相同的 myUserApp1，即使您可能有另一个服务帐户 myUserApp2 用于第二个容器持久数据。