为什么Git有工作区、暂存区和本地仓库？

Question

我试图理解为什么Git有很多地方可以存储更改。想象一个更简单的Git模型，它只有一个本地仓库（没有单独的暂存区或工作区）。在这个模型中：

1. 我们可以选择要跟踪的本地仓库文件
2. 我们可以通过在不同的时间点拍摄仓库的快照来跟踪更改
3. 我们可以像往常一样获取origin/master的更改并进行合并
4. 我们可以有多个分支并在它们之间切换
5. 我们可以像往常一样从本地仓库推送更改到“origin”

换句话说，我们几乎可以做所有Git现在所做的事情，但没有工作区、暂存区和本地仓库的概念混乱。为什么同时拥有三者很有用呢？

- nickackerman42

---

不清楚您认为存储更改的不同位置是什么。 - chepner

我认为工作区、暂存区和本地仓库是存储更改的三个不同位置。在工作区，您将更改存储在文件中；在暂存区，作为已跟踪的更改；在本地仓库中，作为提交。 - nickackerman42

如果您从未使用git add从本地更改的子集构建提交，则可以忽略暂存区，而本地仓库和工作区之间的区别基本上是源代码控制整个概念的基础。您到底想要摆脱什么？ - chepner

我不想丢弃任何东西。我想了解为什么拥有工作区和暂存区很有用。你说工作区和本地仓库之间的区别对源代码控制来说是“基本的”。你能举个例子说明这种区别有什么用处吗？ - nickackerman42

Answer 1

有很多关于git的书籍被写出来了。也许你需要的是关于工作区和暂存区什么时候会有用的具体例子。

工作树 / 工作区

1）你正在构思一个好主意，但它还没有准备好放到本地仓库中。经过一些时间的摆弄后，你意识到它不会起作用。你只需将你的工作区重置到本地仓库即可。

如果你直接在本地仓库上工作，你可能会i)弄脏你的提交历史，ii)要处理回滚问题。

2）或者，假设你想合并两个可能存在冲突的分支。您可以使用 git merge --no-commit ，然后在工作区手动清理，然后将其暂存并提交到本地仓库。

暂存区

1）你已经在工作区解决了一个bug。看着待办事项列表，你意识到这个bug修复实际上包含两个独立的概念部分，分别解决了两个不同的基本问题。

有了暂存区，你可以先把 bug 修复的第一部分 'stage'，并将其提交到本地仓库。然后，你可以 'stage' bug 修复的第二部分，并将其单独提交。

2）或者，例如，你已经更改了一个文件。使用暂存区，你可以只提交该文件的一部分（通过补丁）到本地仓库中。所有更改都在 '工作区'，但只有一个子集会被 'stage' 进行提交。我经常把 README 和 CHANGELOG 的部分文件放进暂存区。

- rmharrison

---

谢谢，这些是有帮助的例子。 - nickackerman42

@nickackerman42 如果答案足够详细，请标记为已回答和/或点赞，这是最佳实践。 - rmharrison

@nickackerman42，顺便提一下，你所说的“工作区”在Git官方术语中被称为“工作树”或“工作目录”。我们理解你的意思，但最好使用本地稳定的术语;-) 请参阅git help glossary。 - kostix

@nickackerman42，请注意Git允许您几乎完全忽略暂存区的存在：git commit命令理解-a命令行选项，基本上告诉它“提交到目前为止已经更改的所有内容”，因此只有在需要添加新文件时才使用git add。我要强调的是这不是工作方式——大多数新手在适应后实际上会欣赏这些多个Git树的概念——只是指出了不同的可能性。 - kostix

@nickackerman42认为如果我使用操作员的术语，那么理解起来会更容易。已更新为正确的术语。 - rmharrison