git checkout混淆了

Git有一个普遍的问题，即将大约八到十种不同的东西塞进一个命令中。注意：Git 2.23正在拆分其中的一些内容，可以肯定的是，这很有帮助，但还是很大的变化。（应该将Git 2.23称为Git 3.0吗？Git 2.0改变了行为git add，在我看来这在程度上也差不多。）另请参见VonC的回答。

git checkout 可以更新工作树，通常可以。

它可以更改HEAD要点的位置，有时可以，有时不可以。

万一您想重置文件并撤消工作，它可以覆盖您对文件所做的工作。或者，它可以拒绝覆盖您对文件所做的工作，在更改HEAD或不更改时保持不变HEAD。

关于这一切的事情是，尽管很难描述，但实际上这一切都是有道理的，经过一段时间后，您习惯了这一点，并且发现一个命令在大多数情况下都能满足您的要求。（当然，这可能是“大多数时候”的问题。

无论如何，您看到的特定行为是故意的。假设您master像大多数存储库一样从branch开始：

$ git clone ...
$ git branch
* master
$

此时，您可以编辑一些文件，进行一些工作，然后才意识到：“啊！我打算在分支上这样做develop！” ^1个

git此时允许您执行的操作是切换到（或创建）分支develop，并将修改保留在一种情况下：切换到develop不需要清除它们。假设您修改了文件f1并创建了一个new f2，现在您要创建并检出develop应该从其开始并自动“跟踪”的本地分支² origin/develop：

$ git checkout develop 

（在git的旧版本中，您必须拼写成git checkout -b develop --track origin/develop）。

假设f1在branchmaster和branch的提示处文件相同develop。³对git而言，这意味着它可以执行此签出操作，因为它不必修改file f1，因此可以将您现有的更改保留f1在原位。

如果文件f2是同时在两个提交相同，或者（在这种情况下）在任何一个不存在，则没有文件会被打一顿，并且git checkout将创建新的本地分支develop，修改工作树相匹配origin/develop的需要，而这不包括修改f1或删除f2，因此到目前为止您所做的工作保持不变。

这使您可以将新更改提交到本地develop。

（如果遇到git确实必须撤消更改，但仍然想将它们“移动”到另一个分支的情况，通常的技巧是使用git stash脚本。这听起来很简单，而且git stash通常很容易使用，但实际上它是一个非常复杂的小动物。不过，直到您需要它时，都不必担心。）

¹这发生在我身上所有的时间。很多时候，我想创建一个新的非跟踪分支，这比切换到现有分支要简单一些，但是原理仍然适用。

²这种自动跟踪功能使您可以更轻松地引入其他人所做的更改：git用拾取它们后git fetch，git会通知您这些其他人的更改，并允许您使用git merge或git rebase将更改与其他人组合在一起，而无需很多额外的戳记，以找出谁的变化去哪里。

³因为你是新来的git，区分一样，这是一个具体的承诺“的一个分支一角”，从“分支”，这实际上是概念模糊的，有分支的标签，然后有分支结构的形成提交树-是您暂时应该忽略的其他内容。需要注意的主要事情是，git存储库中有一个名为的HEAD特殊文件，在该特殊文件中，git编写字符串ref: refs/heads/master或ref: refs/heads/develop，以便跟踪您所在的分支。所以git checkout X会写ref: refs/heads/X到HEAD一旦切换到分支X。

同时，存储库中的另一组特殊文件告诉git，分支master指向像一样大的丑陋SHA-1中的一个c06f8d11b75e28328cdc809397eddd768ebeb533。这是分支的“技巧” master。当您在上进行新的提交时master，git会“在旧提示之后”创建新的提交，然后将新的SHA-1写入分支文件，因此master现在是您的新提交。

精确的细节无关紧要，因为新提交只是推动分支提示的想法无关紧要。