Git:为什么我必须提交其他人的更改

Question

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

我将一些更改提交并推送到 Git 存储库。我有一段时间什么都不做。与此同时，其他人 promise 并 push 他们的改变。然后我尝试提取他们的更改，但我不能这样做，因为 git status 显示我必须提交一些不属于我的更改。这是什么意思？当我提交这些更改时会发生什么？我应该为这种“提交”使用什么样的提交消息？

显然，Git 的“提交”概念与我习惯的 SVN 非常不同，在 SVN 中，您只需更新即可获取其他人的更改，并且只提交您自己的更改。

Answer 1

目前还不清楚你哪里出错了(你没有给我们足够的信息)但我应该在这里指出两点:

1. 您的 git 存储库和工作目录就是:您的。任何更改都是您要求的更改。您可能根本没有意识到(尤其是当您开始使用 git 的一些更晦涩的功能时)您要求它们。

   当然，SVN 也是如此，但这让我想到了......

2. 虽然 git 和 svn 都可以为您提供“整个存储库” View ，但 svn 鼓励——或者至少不会主动反对——“一次一个文件”模式手术。这在 git 中是可能的(在某种程度上)，但这不是一个好主意，因为您将违背 git 的一般推力，即“一次所有存储库” View 。

这听起来好像您让 git 检查旧提交而不是整个旧提交给自己带来了麻烦:

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

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

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

我不会说“永远不要这样做”，但是如果您这样做这样做，请务必小心:您是在告诉 git “我打算更改 中的 foo.txt em>next promise 与 1 周前的方式相匹配。”

具体来说，git 有一个“索引”(又名“暂存区”)，你可以在其中构建每个“下一次提交”:你修改一些文件，将它们添加到索引/阶段，当你满意时通过分阶段安排，您运行 git commit将该安排转变为新的、完整的提交。

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

要摆脱这种情况，请使用 git reset --hard (使用此命令时要非常小心，因为它会重新设置，即清除索引和工作树中的更改)，或 git checkout您通过检查旧版本破坏的文件的最新版本，以恢复原状。

---

¹更具体地说，这种形式的 git checkout给你留下一个“分离的 HEAD”:它通过找到它的提交 ID 来检查一个特定的提交。这首先确保它不会覆盖任何现有工作，然后设置您的索引和工作树以匹配所选提交，并更新 HEAD持有那个提交ID。如果以后，你git checkout master ，git 可以告诉您您没有对该特定的提交 ID 进行任何更改，并安全地将您放回到“分支主机”上作为 git status将会呈现。所以这种形式的 checkout-old/restore-current 是“更安全的”，因为你不必确保你不会丢失任何工作； git 会为你做这件事。