Question

我想很多习惯于SVN而不是Git的人都会对此感到困惑，所以也许有人可以澄清。

我提交并推送一些更改到Git存储库。一段时间我什么都不做。与此同时，其他人承诺推动他们的变革。然后我尝试提取他们的更改而我无法做到这一点，因为git status表明我必须进行一些不属于我的更改。这是什么意思？我提交这些更改后会发生什么？我应该使用什么样的提交消息来进行此类提交？

。

显然Git概念提交＆＃39;与我习惯的SVN非常不同，您只需update来获取其他人的更改，并只提交您自己的更改。

Answer 1

目前尚不清楚你哪里出错了（你没有给我们足够的信息），但我应该在这里指出两件事：

您的git存储库和工作目录只是：您的。任何更改都是您要求的更改。你可能根本就没有意识到（特别是如果你开始使用git的一些比较模糊的功能）。

当然，SVN也是如此，但这让我感到...
虽然git和svn 都可以为您提供“整个存储库”视图，但svn鼓励 - 或者至少不会主动阻止 - “一次一个文件”模式操作。这在git中是可能的（在某种程度上），但这不是一个好主意，因为你将反对git的一般推力，即“所有存储库同时”视图。

听起来好像你通过让git检查一个较旧的提交而不是整个较旧的提交而让自己陷入困境：

$ git checkout master@{1.week.ago}

这将使您在一周前获得整个存储库（进入您的工作目录），此时您可以根据需要检查单个文件。¹但是如果您只是想查看一个特定文件，比如foo.txt，您可能会想要这样做：

$ git checkout master@{1.week.ago} foo.txt

我不会说“永远不会这样做”，但如果你做这样做，那就要非常小心：你要告诉git“我打算改变<中的foo.txt em> next 提交以匹配1周前的方式。“

具体来说，git有“index”（AKA“staging area”），你可以在其中构建每个“下一次提交”：修改一些文件，将它们添加到索引/阶段，当你满意时通过分阶段安排，您可以运行git commit将该安排转换为新的完整提交。

当您使用git checkout（git checkout [rev] path ...）的特定文件格式时，这会告诉git提取文件的旧版本并将它们写入索引以及工作树。换句话说，你要求git获取文件的旧版本，将其放在工作树中，和 git add结果。

要摆脱这种情况，请使用git reset --hard（非常小心这个命令以及它重新设置，即消除索引和工作树中的更改），或{ {1}}通过查看旧版本来破坏文件的最新版本，让事情恢复原状。

¹更具体地说，这种git checkout形式为您留下了“分离的HEAD”：它通过查找其commit-ID来检出特定的提交。这首先确保它不会覆盖任何现有的工作，然后设置索引和工作树以匹配所选的提交，并且还更新git checkout以保存该commit-ID。如果，稍后，您HEAD，git可以告诉您没有对该特定提交ID进行任何更改，并安全地将您“放在分支主机上”，因为git checkout master将显示。所以这种结账 - 旧/恢复 - 当前形式是“更安全”，因为你不必确保你不会失去任何工作; git会为你做的。

Answer 2

我的猜测是你做了一次合并，导致之前的冲突，你忘了用提交结束它。

然后，git status将告诉您树中未提交的更改，它们包括您通过合并带来的更改。最近足够的Git版本应该告诉你像

这样的东西

$ git status
[...]
You have unmerged paths.
  (fix conflicts and run "git commit")

Git：为什么我必须做出其他人的改变

2 个答案: