Question

这是我今天早些时候发布的问题的后续问题，我是一个git新手，我正在尝试使用git分支机构。

我正在接受

请在更改分支错误之前提交更改或存储更改。

这是我的git设置

我在分支Master中创建了一个文件file1，而不是我添加并提交它   我创建了一个分支b1并切换到那个，在那里我对file1进行了一些更改并提交它。
  我切换回主人，在那里我做了一些改变，我不承诺..
  现在，当我尝试切换到b1时，我收到上面显示的错误..

我的问题是导致此错误的因素是什么？什么是git看到抛出这个错误。

考虑单独项目的这种情况

我在分支Master中创建一个文件temp，而不是我添加并提交它我创建了一个分支'branch1'，现在branch1有一个临时文件的副本我在Master中对临时文件进行了一些更改，但没有提交。

现在当我尝试切换到branch1时，为什么它不会抛出那个错误？根据我的理解，两种情况都是相似的。但它会在第一个场景中抛出错误而不是第二个场景？

SO有谁可以向我解释一下，控制windows之间切换的参数是什么？

Answer 1

我切换回主人，在那里我做了一些改变，我不承诺..
现在，当我尝试切换到b1时，我收到上面显示的错误

如果您对master和b1中存在的文件进行了更改，则在更改回b1时会收到该消息。
分支b1将覆盖master中这些文件中完成的本地修改。

您的第二个方案是对私有文件进行了修改（未在git中进行版本化）：更改分支不会影响其内容，因此无需隐藏。

您会看到many examples of git stash at codesearch：

Amiel Martin points out that：

你有没有发现自己这样做？

$ git checkout some_branch
error: Your local changes to the following files would be overwritten by checkout:
        Gemfile
Please, commit your changes or stash them before you can switch branches.
Aborting
$ git stash
$ git checkout some_branch
$ git stash pop

这是一个很好的小捷径：

$ git checkout --merge some_branch

gitguys provides a good scenario for git stash
This gist允许在一个命令中使用stash-checkout-shash pop。

Answer 2

已经有几个正确的答案，但这是另一种看待它的方式。

想象一下，你被缩小并陷入计算机内部，并被赋予了“成为git checkout命令”的工作。用户执行以下操作：

$ cd somewhere
$ ls
... various commands, etc
$ echo something_extra >> some_file
$ git checkout branch

现在，你去了解git checkout branch需要做些什么。首先你要知道那个要求你做事的人是否在git repo（他是）以及他现在在哪个分支（让我们说master，只是为了具体）。所以切换分支是可能的，这似乎是他想要做的。

接下来，您需要查看切换分支所涉及的所有文件，包括（可能）some_file。

分支some_file中是否有branch版本？当前分支some_file中是否有master版本？如果有，那些是相同的还是不同的？当前工作目录怎么样（并且，因为这是git，“staging area”，又名“index”）？

以下是您的所有可能性：

该文件不在任何一个分支中。它没有任何方式，所以，没问题！
该文件位于master但不在branch中。你应该删除它。

现在，您需要检查是否“安全”将其删除。如果它没有为提交暂存，并且文件的内容与master中的内容匹配，则它是“安全的”。（这意味着，你可能会把它放在那里，当那个人做git checkout master时。）作为一个有点古怪的情况，如果它现在不存在它也是“安全的”：没有什么可以删除。
该文件不在master中，但在branch中。您应该使用branch中的内容创建它。

现在，您需要检查创建它是否“安全”。它是“安全的”，如果它没有上演提交，它现在也不存在。（理论上，它现在应该是安全的，但它已经包含了你应该放入的内容。git checkout虽然在这里给我一个错误 - 考虑到“古怪的”情况，这是奇怪的，{ {1}}通常允许切换。）
该文件同时包含git checkout 和 master。你应该......好吧，这取决于你！两者中的相同，或两者中的不同吗？

最后一个案例变得混乱，特别是“index”和“working directory”之间的区别，但让我们来看看它们：

该文件位于两个分支中，并且两者中的相同。你什么也不做，所以切换分支是可以的，即使文件是分阶段和/或修改的。
该文件位于两个分支中，并且两者中的不同。你应该替换它的内容。如果它没有上演且没有修改（branch没有显示该文件），那么你就可以了。
该文件位于两个分支中，并且两者都不同，和工作目录中的与当前分支中的不匹配git status 或目标分支master中的那个。如果你更换它，你将失去这个人的变化，所以你必须错误。

这里的奇怪案例是：文件已暂存和/或修改，但现在匹配目标分支中的文件。也就是说，有人向branch提出了master中已有的相同更改。在这种情况下，您不必覆盖该文件，因此可以能够切换分支。暂存区域使这更难，因为当您执行结帐时，首先必须将新内容写入暂存区域，然后将其复制到工作目录。因此，在允许branch继续之前，您必须确保它在舞台区域中是相同的（作为目标分支版本）。

但在所有情况下，你的工作是：“确保这个人不会丢失他放在工作目录或临时区域的变化”。如果他会失去一些变化，抱怨并退出。否则，允许结帐，并更新暂存区域和工作树。

（因为git的用户界面是......好吧，我们不要说“故意充满敌意”:-)而是“因历史而复杂”，git checkout branch的“切换分支”动作只是您可以git checkout执行的许多不同事项中的一个。特别是，git checkout实际上是一个不同的命令，它不会切换分支，并且非常乐意覆盖更改。只需确保您在此处git checkout rev path，而不是git checkout branch。如果所有“覆盖”用法都有不同的动作动词，我会更高兴，但它就是它。

我也跳过了“合并中间”案件。如果您有合并冲突，则会始终修改暂存区域并且永远不会匹配，因此您在此处输入错误。如果没有合并冲突，git checkout branch and some file names将照常进行，如果成功，则中止合并。我不确定我是否喜欢后一种操作 - 手动设置用户checkout似乎更安全 - 但在这种情况下“丢失”的任何工作仅仅是在合并期间做出的选择，就好像那只是“仅仅”。 ..）

Answer 3

当工作目录发生更改时，如果在其他分支中的文件可用的更改之外无法应用，则会收到错误。

在第一个场景中，master和branch已经分道扬.. file1中更改了b1。它不是主人。但是你在master的版本上进行本地更改，并切换分支。现在无法应用更改，因为file1中的b1版本与基本版本的版本不同。

在方案2中，两个分支中文件的基本副本相同。现在任何分支签出时的本地更改都是相同的，您可以轻松地在它们之间切换。

Answer 4

当切换分支时，git将更改工作目录中的文件以匹配您要切换到的分支的文件。

然而，未经修改的变化会发生什么？确实，他们会被覆盖。由于他们没有承诺，他们将永远失去。

为了防止这种情况发生，git会发出警告，告诉您提交或存储这些未经注释的更改。有几种方法可以摆脱这种警告：

无论如何都要切换分支（这会松掉未经修改的更改）
提交更改
存储更改

无论如何切换分支是通过在切换分支之前执行git reset --hard HEAD来完成的。该命令将覆盖所有未提交的更改。

什么时候我必须在切换分支时存储git中的本地更改？

4 个答案: