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

Cri*_*scu 23 git mercurial tortoisehg staging

该汞文档状态hg不支持等同于Git的指数开箱即用,并使用类似的行为扩展(记录或MQ)建议.

首先,我的实地经验非常少git,所以让我说明我对git中升级概念的理解:

有工作副本,包含许多已更改的文件,每个文件都有许多已更改的块.
然后,用户(可能重复地)用于git add选择将提交哪些文件.
或者,用于git add -p仅选择文件中的某些块以便稍后提交.
执行a git commit将以前选择的更改添加到存储库.

因此staging area,对我来说,整体而言是一个浮夸的名称,用于选择工作副本中的哪些更改将在下一次提交中进行.

如果我还没完全关闭,那么,为什么每个人,包括官方文档,都说明Mercurial不支持这个？

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

在此输入图像描述

在左侧窗格中 - 选择要包含在提交中的整个文件
在右下方窗格中 - 选择要包含的单个块
点击"提交".

我不知道hgTortoiseHg使用什么命令,但是我再也不需要关心了.(它没有使用此AFAICT的任何扩展名)

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

Amb*_*ber 30

登台区域(索引)记录更改快照,而不仅仅是选择的文件.例如,您可以修改要添加的foo文件A,暂存文件A,然后再次修改文件A以进行添加bar.如果不重新暂存文件A,那么在提交时,只会 foo提交,因为索引在暂存时具有A的快照.

您还可以将文件还原回最后一个索引快照的状态(通过git checkout).从本质上讲,索引就像一个"临时提交",在实际提升为完全提交之前很容易修改.

由于索引是持久的,如果你在中途进行中途,那么决定你需要进行另一次更改,没问题 - 只需进行更改,然后暂存新版本.无需重新安排您已经上演过的所有其他事情.

在提交之前意外删除了一个文件？如果你已经上演了它,不用担心 - 只需查看分阶段版本.

哈!所以索引*不仅仅是一个"选择",而是一个真正的树,种类.谢谢 - 这让事情变得透彻.我找到了一个[*很棒的文章](http://git-scm.com/blog/2011/07/11/reset.html)(由*Pro Git*的作者)为凡人解释`git reset` ,它建立在这种知识的基础上. (5认同)

gav*_*koa 5

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

它的设计目的不是让普通开发人员易于使用（与hg！相比），但是由于其成本，性能，大型公司的支持和广告活动而获得了广泛的欢迎和文化地位（GitHub在此处）。

如今，普通开发人员可以通过IDE GUI与Git进行交互，而无需了解Index / Stage区域。它仅使用复选框，如asker屏幕截图中所示（因此普通开发人员在Git / Mercurial用法之间没有区别）。

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

这是描述索引用法的漂亮图像：

您总是可以通过以下方式模拟Index（但是为什么？）：

hg qinit
hg qadd
hg qrefesh
hg qfinish

Run Code Online (Sandbox Code Playgroud)

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

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

因此，主题入门者实际上是正确的，认为Index是DVCS体系结构的不必要功能，它内置于Git中以支持某些Git核心开发人员的意愿。

祝你好运，黑客入侵愉快！

更新报价来自http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Git的大多数功能都直接针对代码库的维护者：必须合并来自许多不同来源的文稿的人，或者必须确保大量并行开发工作的人才能产生单一，一致且稳定的版本。很好但是大多数Git用户都没有这种情况：他们只是简单地编写代码，通常一次在单个分支上写几个月。Git是一台4柄双锅炉意式浓缩咖啡机，当他们需要的一切即刻即可。