什么是 git staging 以及为什么 Hg *表面上 * 不支持它？

Question

Hg docs 声明 hg 不支持开箱即用的 git 索引，并建议使用扩展（记录或 mq）来实现类似的行为。

首先，我对git的现场经验很少，所以我来说一下我对git中暂存概念的理解：

• 有一个工作副本，其中包含许多已更改的文件，每个文件都有许多已更改的块。
• 然后用户（可能重复）使用git add 来选择要提交的文件。
• 或者，使用git add -p 仅选择文件中的某些块以供稍后提交。
• 执行git commit 将先前选择的更改添加到存储库。

所以对我来说，整个staging area 是一个浮夸的名字，用于选择工作副本中的哪些更改将在下一次提交中进行。

如果我不完全同意这一点，那么为什么每个人（包括官方文档）都声明 Mercurial 不支持这一点？

我在问，因为上面的确切工作流程在 TortoiseHg 中是微不足道的：

• 在左侧窗格中 - 选择要包含在提交中的整个文件
• 在右下窗格中 - 选择要包含的单个块
• 点击“提交”。

我不知道hg TortoiseHg 使用什么命令，但话说回来，我从来不需要关心。 （它不使用此 AFAICT 的任何扩展）

我还缺少git 的分期概念吗？

Answer 1

暂存区（索引）记录更改快照，而不仅仅是文件的选择。例如，您可以修改文件 A 以添加 foo，暂存文件 A，然后再次修改文件 A 以添加 bar。如果你不重新暂存文件 A，那么当你提交时，只有foo 会被提交，因为索引有暂存时 A 的快照。

您还可以将文件恢复到上次索引快照的状态（通过git checkout）。从本质上讲，索引就像一个“临时提交”，在实际提升为完整提交之前很容易修改。

由于索引是持久的，如果您在暂存工作中途完成，然后决定您需要进行另一次更改，没问题 - 只需进行更改，然后暂存新版本。无需重新上演您已经上演的所有其他内容。

在提交前意外删除文件？如果您已经上演过，不用担心 - 只需查看上演过的版本。

Answer 2

Git 旨在支持 Linux 内核开发期间的某种工作流程。由某种人为某种人。

它不是为普通开发者易于使用而设计的（与 hg 相比！），但由于其成本、性能、大公司支持和广告活动（此处为 GitHub）而获得了广泛的知名度和文化地位。

如今普通开发者通过 IDE GUI 与 Git 交互，不需要了解 Index/Stage 区域。它只是像询问者屏幕截图那样使用复选框（因此普通开发人员使用 Git/Mercurial 没有区别）。

对于使用 Git 的命令行不规则 CLI 语法并暴露不必要的存储格式细节的人来说，学习时间比成为 Mercurial 向导的时间更长。

这是描述索引使用的漂亮图片：

• https://marklodato.github.io/visual-git-guide/index-en.html
• http://git-scm.com/blog/2011/07/11/reset.html

你总是可以模仿 Index by（但为什么？）：

hg qinit
hg qadd
hg qrefesh
hg qfinish

除了 MQ 允许您拥有一组有序的索引，而不仅仅是一个！并允许您为每个“索引”命名。

使用record 扩展，您可以在 CLI 中选择补丁块，就像在 GUI 中选中复选框一样。该扩展是对 Git -p 选项的直接回答。

所以 topic starter 实际上是正确地填充了 Index 是 DVCS 架构的不必要功能，并且内置在 Git 中以支持一些 Git 核心开发人员的意愿。

祝你好运，黑客愉快！

更新引用http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Git 的大部分功能都是针对代码库的维护者的： 必须合并来自大量不同的贡献的人 来源，或者谁必须确保一些并行的开发工作 导致单一的、连贯的、稳定的释放。这很好。但是 大多数 Git 用户并不处于这种情况：他们只是编写代码， 通常一次在一个分支上几个月。 Git 是一个 4 句柄，双 锅炉浓缩咖啡机——当他们需要的是即时的时候。