git update-index --assume-unchanged刚刚停止工作

时间：2018-08-01 15:12:12

标签： git visual-studio-2017

我们使用此命令忽略Visual Studio 2017中ASP.Net Core MVC应用程序中的appsettings.json文件。

$ git update-index --assume-unchanged Doed.Aarts.Net.Web/appsettings.json

或

$ git update-index --no-assume-unchanged Doed.Aarts.Net.Web/appsettings*.json

这很长时间以来一直运行良好。 今天，我对appsettings.json进行了更改，并注意到更改显示在更改中。

我本来以为我只是搞砸了一些东西，所以我重新设计了项目，从头开始。 打开git bash并应用假定不变的命令。

但是我无法使其重新工作。

对于弄清楚这里可能发生的情况的任何建议，我们将不胜感激。

我已经检查了路径，以确保我从正确的位置开口并指向正确的路径。

但是仍然有问题。

2 个答案:

答案 0 :(得分：2)

这实际上对每个人都有效。 它从未真正中断过。自从我关注它已经很久了，我忘记了每一步的样子。

如果有人正在研究如何做到这一点。

这些是正确的命令： 为了使文件的更改不会像更改一样被跟踪，并且不要坐在那里等待上演：

$ git update-index --assume-unchanged Doed.Aarts.Net.Web/appsettings.json

您还可以在appsettings * .json之类的名称中使用通配符。

要关闭，请使用：

$ git update-index --no-assume-unchanged Doed.Aarts.Net.Web/appsettings*.json

因此，如果我对此文件进行了更改，这就是Visual Studio 2017中的外观。

enter image description here

请注意Team Explorer中文件名旁边的星号。

现在，当我保存文件时，它将从更改中消失。 但是我的本地文件保留了修改。

我们在项目中使用它是因为源回购中的版本在appsettings中具有令牌，这些令牌已被替换为不同环境中的各种构建。每个环境都需要不同的值，因此我们保留要替换的令牌。

但是在本地，我们将令牌替换为运行和开发所需的硬编码值。

希望这一切都有道理并能帮助到别人。

答案 1 :(得分：-2)

请参阅Git - Difference Between 'assume-unchanged' and 'skip-worktree'。我不会将其作为重复项关闭（还好吗？）。

  

今天，我对appsettings.json进行了更改，并注意到更改中显示了更改。

这需要您提供更多详细信息，因为“更改”不明确。您是说它显示在git status中吗？您是说如果对两个提交运行git diff，则文件在这两个提交之间显示为已更改？还是您完全是在说其他话？

要了解的重要背景

索引（也称为临时区域和缓存）是关键的Git数据结构。它包含将进入您所做的每个提交的每个文件，并且开始包含您从某个开始提交中提取到工作树（您执行工作的目录）的提交中的每个文件。也就是说，一旦有了Git存储库（一个提交集合），您就可以使用git checkout将一个 specific 提交提取到您的索引和工作树中。

通常，所有这些操作都发生在初始git clone上，其最后一步是git checkout master。这会将您带到与现有master相同的 tip commit 中名为origin/master的自己的（新创建的）分支，所有分支均由{{1}获得}命令。即git clone：

  1. 创建一个新的空存储库（零提交的集合），其中包含空白的 index 和空的工作树。

  2. 从另一个Git（现在您有很多提交）填充存储库。索引仍然为空/空白，工作树也是如此。

  3. 使用其分支名称（例如其git clone）创建您的远程跟踪名称，例如master。每个这样的名称都标识一个提交。随着时间的流逝，您和您的Git以及您要从中克隆的其他Git将安排这些名称来标识其他（通常是较新的）提交，尽管在任何时候每个名称仍将准确地标识一个提交。

  4. 根据您的Git刚根据{em>他们的 Git的origin/master创建的master创建自己的origin/master。 （要理解为什么您的master和他们的master并不总是标识相同的特定提交，所有这些复杂性都是必需的。它们开始相同，并且您经常一旦它们变得不同，就使它们再次变得相同，但是它们是分开的！您的master是您的Git对他们的Git origin/master的记忆，因此您的master遵循他们的{{1} }。您自己的origin/master是您的，您可以照做。）

  5. 最重要的是，您的Git（作为master的最后一步）提取此特定提交的内容，插入您的索引和进入您的工作树。那就是您要处理的文件的来源！

根据索引中的内容进行新的提交

在不同的时间，您将修改工作树中的一个或多个文件，然后执行以下操作：

master

新提交使用存储在 index （不是工作树！）中的任何文件进行新提交。 Git使用索引而不是工作树的事实是为什么，您必须git clone更改文件：索引开始时保存文件 all ，它仍然保存 all 个文件，但是当您修改工作树中的文件时，索引中的文件没有更改。

git add file1 file2 ... fileN # or git add --all, or git add ., etc git commit # with options if desired 的作用是将工作树文件复制到索引中，从而覆盖当前在索引中的副本。因此，通过添加文件，您已经更改了索引中的版本（以匹配工作树中的版本）。这意味着您提交的 next 提交将具有文件的新版本，而不是具有相同文件的旧版本。

这很关键，因为git add使用 index 而不是工作树进行提交！如果您从未git add path索引中已经存在文件 ，则意味着新提交仍具有文件 ，但是该文件具有以前的版本。

请注意，您始终需要关注每个文件的三个版本：

  • 当前提交中的版本：例如git commit。该文件的版本是提交内的 。它无法更改，因为任何提交的任何部分都无法更改。

    您需要将此内容存在于提交中 中，以便以后add或git show HEAD:README.txt可以将其复制到提交中 out 到索引和工作树。该文件的版本为特殊的仅Git格式。它被压缩，有时效果非常好。

  • 例如索引中的版本：git clone。此版本是当前在索引/暂存区域中的。可以更改 。现在无论里面有什么，都将进入您创建的下一个git checkout。

    此文件的版本也是特殊的，仅Git的格式。索引版本和git show :README.txt提交版本之间的主要区别在于，您可以覆盖索引版本。无论运行git commit时其中包含什么内容，那个版本都会被冻结到该新提交中，并因此被永久保存（或只要新提交仍然存在）。

  • 工作树中的版本：在文件上运行编辑器，编译器或其他内容时所获得的结果。尽管它是您可以直接使用的唯一版本，但它本身对Git本身并没有多大兴趣。您可以使用它，因为它不是特殊的，仅Git格式的 not 。

    此文件的版本主要对HEAD而言对Git有用：git commit将此版本压缩为一个新的，特殊的，仅Git格式的文件，Git将该文件填充到索引中，以替换任何内容之前在那个索引槽中。 you 对您很有用，因为它是普通文件，但是Git不必关心它，因此也不在乎。

运行git add时，Git进行两个单独的比较：

  • 首先，Git将git add提交与索引进行比较。这里的不同都是“上演提交”。这是因为，如果您现在进行提交，Git将使用索引中的 everything 进行提交。因此，此新提交（将成为当前提交）将因索引不同而与当前提交有所不同。

  • 第二，Git将索引与工作树进行比较。这里的不同都是“未上演提交”。也就是说，您可以使用git status将工作树文件复制回索引。如果您不这样做，则下次提交将没有此版本的文件。

请注意，您可以使文件的所有三个版本都不同！例如，签出一些提交后，您可以修改工作树文件，将修改后的文件复制到索引中，然后再修改工作树文件。现在，您已经进行了 的提交更改，因为HEAD和git add不同，和的更改不是 因为git show HEAD:file和Git不会直接使用但在您的工作树中的文件的内容也有所不同，所以准备提交。

索引中的控制位

您可以在索引中的条目上设置两个控制位：假定不变和跳过工作树。可以使用git show :file，git show :file，git update-index，--assume-unchanged和--no-assume-unchanged选项来设置（或清除）它们。

“假定未更改”和“跳过工作树”位不会使Git 忽略。相反，它们会影响 Git将文件的索引版本与文件的工作树版本进行比较的方式。将任一位置1意味着--skip-worktree或--no-skip-worktree >不会将工作树版本复制到索引中，而git add . 不会将索引版本与工作树版本进行比较。

不会更改git add --all-vs-index比较工作的方式。它不会更改git status从索引中的内容构建新提交的方式。它只会影响Git是否会费心比较索引和工作树版本，以及是否会为进行HEAD操作而自动从工作树复制到索引。

这两个控制位具有不同的意图：假定不变旨在用于git commit非常慢的机器上以加快速度，而跳过工作树 >意味着您正在做什么。因此，您应该使用git add。但是，两者通常应具有相同的效果。

这两个位都将跳过索引内容与工作树内容的比较。 Git仍然需要将文件从工作树复制到索引中以进行更改，因此，如果您不将文件复制到索引中，则文件不会更改。每个新的提交将具有该文件的相同旧版本。

请注意，如果您git status进行一些 other 提交，或合并从其他Git获得的提交，或者更改了哪些提交为当前提交 ，Git必须用新版本替换该文件的索引版本。当Git执行此操作时，Git将要覆盖文件的工作树版本。如果Git需要覆盖文件的工作树版本，则Git将-不考虑任何控制位-首先检查它是否会覆盖您从未提交的内容。

如果更改，则当前提交需要更改文件的索引版本，并且您的工作树中有未提交的内容，这些控制位都不存在停止Git抱怨。这是正常的，对您有用，因为这意味着您必须将文件的 （工作树）版本保存在某个地方，然后允许Git执行以下操作：用您打算用作新的当前提交的任何提交中的新版本替换您的工作树版本。一旦发生这种情况，由您决定是否将保存的工作树版本与从当前提交中提取的一个Git进行协调，并可能再次设置其中一个控制位。

相关问题
最新问题