如何解决Git pull 不起作用，并且将本地文件显示为已修改且未经修改 进一步阅读可选
我正在尝试从目录外部执行 git pull，我正在运行以下命令：
git --git-dir=$WORKDIR/sources/.git pull
输出是“Alrady Up To Date”或者它只是“拉取”修改但文件不是远程文件，即使 git pull 输出显示它应该是，并且 git status 显示文件被“修改”，就好像他在 git pull 后保留本地版本并告诉我我修改了它。
我该如何解决这个问题？我已经了解了 --work-tree 选项，但我不知道它是否会以某种方式产生影响。
解决方法
我正在尝试从目录外执行 git pull ...
不要那样做。 （你为什么要这样做？）
git --git-dir=$WORKDIR/sources/.git pull
In a comment,ElpieKay suggests:
添加--work-tree=$WORKDIR/sources
您回复的对象：
似乎现在可以工作
当你同时使用这两个选项时，Git 会：
- 重新定位到您的工作树，
$WORKDIR/sources; - 使用
$WORKDIR/sources/.git作为正确的存储库； 和 - 在那里运行 Git 命令。
这对选项 - 除了覆盖任何环境 $GIT_WORK_TREE 和 $GIT_DIR 变量 - 与执行相同：
git -C $WORKDIR/sources pull
其中 -C 导致 Git 在运行 git pull 之前首先更改目录。这将是从该位置运行 git pull 的一种更典型的方式：具有单独 --git-dir 和 --work-tree 选项的变体允许您将 .git 与工作树分开，在相对罕见的情况，它很有用，并覆盖任何早期的环境变量设置。1
1当您使用这些选项时，Git 本身会设置这些相同的环境变量。所以：
git --git-dir=A --work-tree=B whatever
工作方式完全相同：
GIT_DIR=A GIT_WORK_TREE=B git whatever
除了后一种形式采用 POSIX 风格的 shell（命令行解释器）。
进一步阅读（可选）
您能否就为什么需要此选项提供任何见解？
Git 存储库 实际上只是 .git 目录中的内容。存储库主要由两个数据库组成：
-
一个——通常更大——由 Git 的提交和其他内部对象组成。它们通过它们的散列 ID 进行编号和检索。 提交 哈希 ID 尤其是始终是唯一的，并且要检索提交，Git 需要知道其编号。
-
另一个数据库由名称组成，例如分支和标签名称，每个名称都映射到一个哈希 ID 号。这允许您使用分支或标签名称来检索提交。添加新提交通常涉及更新分支名称或远程跟踪名称，以便能够找到新提交。
每个提交都包含每个文件的完整快照，作为一种只读存档。 Git 压缩这些快照（以多种方式）并删除快照中内重复的文件，因此在许多情况下这占用的空间非常小。这种压缩技术并不完美——它在存在许多大型预压缩二进制文件时往往会失败——但它非常适合人类可读文件，例如软件的源代码。 >
提交本身也包含提交编号——或者数字，复数，用于合并提交——它们的直接前一个提交。因此，只要 Git 可以找到 最后 次提交（通过分支或其他名称），Git 就可以使用它们来查找 每个较早的提交，一次一个步骤，通过向后看的链条。这是存储库中的历史记录：History = commits，从最后开始向后工作。
但是有一个问题。这些只读、压缩的提交/文件只能由 Git 本身使用。你可以用这些做的主要事情是与其他一些 Git 交换它们。您还可以将它们与 git diff 或类似内容一起使用，并对项目随时间的变化进行一些分析，等等。但是你不能取得任何进步。你无法完成新的工作，只有由两个数据库组成的存储库。
要完成工作，您需要一个工作树。在这里，您将拥有 Git extract 提交。提取的提交将存档（压缩、只读、Git 化、无用）文件扩展成日常（有用）的形式。我们称之为签出分支或提交。 （何时以及是否称其为“分支”与“提交”是很多混淆的根源，因为人类在这里不一致，有时也无知细节。棘手的部分是当我们有一个branch 签出，我们也有一个 commit 签出。当我们只 签出一个提交时——通过 Git 所谓的“分离的 HEAD” “——我们仍然有一个提交被检出，但不是一个分支。）
非裸存储库定义为具有工作树的存储库。裸仓库是指缺少工作树的仓库。这基本上就是全部内容，但是缺少工作树意味着该存储库可以接收新提交无条件。具有工作树的 Git 存储库无法安全地接收检出分支的新提交。所以服务器（托管）站点通常存储裸存储库。
当你运行 Git 命令时，如果你有一个工作树，你应该在工作树内运行它们。如果您有充分的理由希望从该工作树的外部运行 此外，当您确实有一个工作树并且没有使用所有这些复杂的方法将存储库从工作树中分离出来时，Git 需要一个 Git 将查看此路径中是否存在 不过，在你的情况下，你跑了： 这告诉 Git：Git 目录是（无论 由于 Git 还存储了 Git 称为其index（或暂存区或缓存，取决于Git 的哪一部分正在执行此“调用”）。这实际上只是存储库目录中的一个文件，例如 git pull 命令的意思是：首先，运行 git fetch，然后运行第二个 Git 命令来对 {{1} } 步骤。 fetch 步骤在裸存储库中运行良好，但第二个命令——无论你选择哪个命令来运行 git fetch——需要一个工作树。
git pull，您可以使用 git，如上所示。您还可以使用 git -C working tree path 或 $GIT_WORK_TREE 参数。--work-tree 目录（或文件）存在于 顶层。事实上，在没有所有这些花哨的将两部分分开的技巧的情况下，这就是 Git 如何找到工作树的顶层。假设您在：.git/path/to/some/working/dir/ectory
。如果没有，Git 将去掉 .git 部分并重试：是否有 ectory？如果没有，Git 将去掉 /path/to/some/working/dir/.git 部分并重试：是否有 dir？如果是这样，Git 已经找到了你工作树的顶层，以及这里的 /path/to/some/working/.git——无论它是一个文件，包含 .git 目录的位置，还是目录本身，因此 .git 目录 — 确定存储库本身所在的位置。.gitgit --git-dir=$WORKDIR/sources/.git ...
扩展到什么——这个扩展是由 shell 完成的，而不是由 Git 完成）$WORKDIR。所以 Git 不必搜索顶层。您没有告诉 Git 工作树的顶层在哪里，所以它只是假设您的当前目录是工作树的顶层工作树。但实际上，您当前的目录是别的东西。 Git 可能因此损坏了各种文件，理由是它们来自您的工作树。/sources/.git。 （文件的确切位置可能会有所不同，有时还有其他文件，所以不要在这条路径上计算太多。记住 .git/index 但如果它有助于有一个具体的模型来说明“索引”是什么.) 在这个索引中，Git 存储关于它已经检出哪些文件的信息。索引的存在，加上假设您已经处于工作树的顶层，这就是 .git/index 行为不正确的原因。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。