快照的概念 [英] The concept of snapshot

问题描述

在Git中有一个快照概念基本术语

这个概念在Git工作流中使用：

$ b $您可以修改您的工作目录中的文件。 您的分段
区域。


1. 您执行一个提交，它将文件原样存储在
   暂存区域中，并将<




快照永久存储到您的Git
目录中。 p>您能否准确解释什么是快照，并显示一些小文件示例，它是快照，以及为什么Git使用它们而不是像在其他VCS中一样区别？


解决方案

快照只是表示文件内容在给定时间点的内容。所有版本控制系统都在概念上在快照上运行。您希望能够看到过去任何时候您的源代码的样子。它们也都存储差异以节省存储空间。 git的独特之处在于两个方面：差异计算和内部存储的方式与文件的历史没有直接关系，每次差异都不会重新计算。





假设您有一个1000字节的文件，几乎可以在每个版本上进行更新。如果你改变它的一个字节，git会临时存储一个全新的文件副本，并改变一个字节。这是人们翻出来说OMG，git是如此愚蠢，它应该马上存储差异，我坚持颠覆。



然而，想想你实际上如何使用你的源代码控制。几乎所有你想和之比较的东西都是自上次推送以来发生变化的东西。因为它还没有计算出差异，所以git恰好有一个完整的，容易访问的所有那些最近更改过的文件的缓存，其中的版本控制系统必须从版本1开始，并应用数百个差异来重构相同的内容。
$ b 然后，当您执行分享您的更改时，会自动运行 git gc 以存储这些更改文件更有效地通过网络传输，然后计算并存储差异。但是，它不一定是从版本n-1到版本n的文件差异。如果内容在许多文件中重复，git可以考虑这一点。如果在多个分支中进行相同的更改，git可以考虑这一点。如果文件被移动，git可以考虑到这一点。如果将来发现一些启发式方法可以使事情变得更加高效，那么git可以在不破坏现有客户端的情况下考虑到这一点。它不符合差异必须始终从一个连续版本到下一个版本的想法。





这些基本的设计决策使git与其他版本相比如此之快控制软件。


There is a concept of snapshot in Git basic terminology.

This concept is used in Git workflow:

1. You modify files in your working directory.

2. You stage the files, adding snapshots of them to your staging area.

3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Could you explain exactly what is snapshot and show some small example of files and it's snapshots and why Git uses them instead of making differences as in other VCSs?

解决方案

A snapshot just means what a file's contents were at a given point in time. All version control systems operate conceptually on snapshots. You want to be able to see what your source code looked like at any given point in the past. They also all store diffs in order to save storage space. Where git is unique is in two ways: the way diffs are computed and stored internally isn't directly related to the file's history, and the diffs aren't recomputed every single time they could be.

Let's say you have a 1000-byte file that gets updated on practically every build. If you change one byte of it, git will temporarily store a completely new copy of the file, with the one byte changed. This is where people flip out and say, "OMG, git is so stupid, it should store the diffs right away. I'm sticking with subversion."

However, think about how you actually use your source control. Almost everything you want to do comparisons with are things that have changed since the last time you pushed. Because it hasn't computed the diffs yet, git just happens to have a full, easily accessible cache of all those recently-changed files, where other version control systems have to start with version 1 and apply hundreds of diffs to reconstruct the same content.

Then when you do a push to share your changes, git gc is run automatically in order to store those files more efficiently for transport over the network, and diffs are computed and stored then. However, it's not necessarily a diff from version n-1 to version n of the file. If content is repeated across many files, git can take that into account. If the same change is made in several branches, git can take that into account. If a file is moved, git can take that into account. If some heuristic is discovered in the future that can make things more efficient, git can take that into account without breaking existing clients. It's not wedded to the idea that the diff must always be from one consecutive version to the next.

It's fundamental design decisions like these that make git so fast compared to other version control software.

这篇关于快照的概念的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！