Git中的提交:是快照/状态/图像还是更改/差异/补丁/增量? [英] A commit in Git: Is it a snapshot/state/image or is it a change/diff/patch/delta?

问题描述

• Git中的某些操作(例如checkout)似乎假定提交是工作树的快照或状态.
• Git中的其他操作(例如rebase)似乎假定提交是更改:一种可以应用于工作树的运算符.

• Some operations in Git (e.g. checkout) appear to assume that a commit is a snapshot or state of the working tree.
• Other operations in Git (e.g. rebase) appear to assume that a commit is a change: a kind of operator that can be applied to working trees.

那么，什么是Git提交呢?

So what is a Git commit, really?

推荐答案

了解Git粒子/波对偶性

简短答案: 两者.

中等答案: 要视情况而定.

长答案: Git有点像量子现象:两种观点都不能单独解释所有观察结果.继续阅读.

Long answer: Git is a bit like quantum phenomena: Neither of the two views alone can explain all observations. Read on.

内部，Git将使用这两种表示形式，(在概念上)取决于它在给定提交的存储空间和执行时间方面认为更有效的一种表示形式.快照表示是主要的.

Internally, Git will use both representations, depending (conceptually) on which one it deems more efficient in terms of storage space and execution time for a given commit. The snapshot representation is the primary one.

从用户的角度来看，但这取决于您的操作:

From the user's point of view, however, it depends on what you do:

实际上某些命令仅在您使用时才有意义 考虑将提交作为工作树的快照. 这对于checkout最为明显，但对于checkout也是如此 stash，并且至少是fetch和reset的一半.

Indeed some commands simply only make any sense at all when you think about commits as snapshots of the working tree. This is most pronounced for checkout, but is also true for stash and at least halfway for fetch and reset.

对于其他命令，当您尝试执行疯狂操作时可能会导致疯狂 以这种方式考虑提交. 对于其他命令，将提交视为更改，

For other commands, madness is the likely result when you try to think of commits in this manner. For those other commands, commits are clearly treated as changes,

• 您可以以补丁的形式查看 (例如show，diff)
• 或以运算符的形式，您可以申请修改您的工作树 (例如apply，cherry-pick，pull)
• 或以运算符的形式，您可以申请修改其他提交 (例如rebase)
• 或以运算符的形式，您可以申请创建新的提交 (例如merge，cherry-pick)

• either in the form of patches you can look at (e.g. show, diff)
• or in the form of operators you can apply to modify your working tree (e.g. apply, cherry-pick, pull)
• or in the form of operators you can apply to modify other commits (e.g. rebase)
• or in the form of operators you can apply to create new commits (e.g. merge, cherry-pick)

对偶1的副作用可能会震惊Git新手 习惯于其他版本控制系统. 这是事实，Git似乎甚至没有承诺自己的承诺.

There is a side-effect of duality 1 that can shock Git newbies accustomed to other versioning systems. It is the fact that Git appears to not even commit itself to its commits.

嗯?

假设您已经创建了一个分支X，其中包含您想要思考的内容 作为您的提交A和B. 但是master有所进步，所以您rebase X到master.

Assume you have created a branch X containing what you like to think of as your commits A and B. But master has progressed a little, so you rebase X to master.

当您将A和B视为更改，但将master视为快照时 (嘿，一个实验中有粒子和波浪！)， 这不是问题: 只需将更改A和B应用于快照master.

When you think of A and B as changes, but of master as a snapshot (hey, particles and waves in a single experiment!), this is not a problem: Just apply the changes A and B to the snapshot master.

这种想法是如此自然，以至于您几乎不会注意到Git 现在已经重写了您的提交A和B:它们现在具有不同的 快照内容，因此使用不同的SHA-1 ID. 在Git中，您认为是开发人员的概念性承诺 不是千篇一律的东西，而是 由于与您的工作而变化的一些易流动的物体 存储库.

This thinking is so natural that you will barely notice that Git has now rewritten your commits A and B: They now have different snapshot content and hence a different SHA-1 ID. In Git, the conceptual commit that you think of as a developer is not a fixed-for-all-times kind of thing, but rather some fluid object that changes as a result of working with your repository.

相反，如果您想到所有三个(A，B和master) 作为快照，或者作为全部三个快照， 你的大脑会受伤，你将无处可去.

In contrast, if you think of all three (A, B, and master) as snapshots or of all three as changes, your brain will hurt and you will get nowhere.

上面是一个大大简化的描述. 在Git现实中，

The above is a much-simplified description. In Git reality,

• 一个提交根本不是快照，它是一个元数据 (快照的 who/when/why )和指向快照的指针；
• 快照在Git术语中称为树；
• 按更改提交"内部表示使用 packfiles ;
• 某些上述命令还具有其他作用 不适合相同的特征；
• 即使对于给定的角色，在某种程度上也只是 品尝某些命令属于哪个类别(或-ies).

• a commit is not a snapshot at all, it is a piece of metadata (the who/when/why of a snapshot) plus a pointer to a snapshot;
• the snapshot is called a tree in Git lingo;
• the commits-as-changes internal representation uses packfiles;
• some of the above-mentioned commands have further roles that do not fit the same characterization;
• and even for the given roles it is to some degree a matter of taste into which category (or -ies) certain commands belong.

并且不要对Pro Git书籍的Git的第一个特征感到困惑(在"快照，而不是差异" .

And don't get confused by the fact that the Pro Git book's very first characterization of Git (in section "Git Basics") is "Snapshots, Not Differences".

Git 毕竟很复杂.

Git is complicated after all.

这篇关于Git中的提交:是快照/状态/图像还是更改/差异/补丁/增量?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！