Git：如何对待提交，以便文件的版本全部存在（而不仅仅是差异） [英] Git: How to treat commit so that versions of a file exist in their entirety (not just as diffs)

问题描述

是否有办法强制Git将文件的版本存储为完整且分离的实体，而不是下游提交，这些提交存在于上游提交的差异中？

有人会问我为什么要这样做。我想这样做是因为我的老板告诉我要这样做。 FWIW，所讨论的特定文件是一个过程的产物，在这个过程中，输入中的一个小变化可能导致文件的重大重构。 解析方案

Git的对象存储已经做到了，而且不可协商。

Git的对象数据库是面向快照的，个别文件是 blob s和目录是树对象。

验证这很容易通过查看 .git / objects 或做

  git rev -list --objects --all 
  

现在，过了一段时间，为了提高效率，对象数据库将被压缩（称为包装）。这样可以提高存储效率，但不会影响增量。

---

背景

RCS，CVS，Subversion和其他人（SourceSafe？）推广了存储增量。主要是因为模型可以很容易地传输变更集，因为它们已经是三角形。现代VCS-es（主要是分布式）已经发展，并且强调数据完整性。
$ b

数据完整性

由于对象数据库的设计，git非常强大，可以检测快照中任何地方或整个回购的任何损坏的数据位。有关Git存储库的加密属性的更多详细信息，请参阅此文章： Linus talk - Git与数据损坏？

在技术喋喋不休中：提交历史形成了密码强大的merkle树。当tip提交（HEAD）的sha1总和匹配时，它在数学上跟着那个

• 树内容


• 分支历史记录（包括所有签名和提交者/作者凭证）

是相同的。这是git（以及其他与之共享此设计特性的SCM）的巨大安全功能。

Is there a way to force Git to store versions of a file as complete and separate entities as opposed to downstream commits existing as diffs from the upstream commits?

Some will ask why I want to do this. I want to do this because I was told to do so by my boss. FWIW, The particular file in question is the product of a process where one small change in the inputs can result in significant restructuring of the file.

解决方案

Git's object storage already does that, and it is not-negotiable.

Git's object database is snapshot oriented, Individual files are blobs and directories are tree objects.

Verify this easily by looking under .git/objects or doing

git rev-list --objects --all

Now, after a while, for efficiency, the object database will be 'compressed' (known as packing). This results in storage efficiency, but does not involve sotring deltas.

---

Background

Storing deltas was popularized by RCS, CVS, Subversion and others (SourceSafe?). Mainly, because the model made it easy to transfer changesets because they would already be in delta form. Modern VCS-es (mostly distributed) have evolved away from that, and put the emphasis on data integrity.

Data Integrity

Because of the design of the object database, git is very robust and will detect any corrupted bit of data anywhere in a snapshot, or the entire repo. See this post for more details on the cryptographic properties of Git repositories: Linus talk - Git vs. data corruption?

In techno babble: commit histories form cryptographically strong merkle trees. When the sha1 sum of the tip commit (HEAD) matches, it mathematically follows that

• tree content
• the branch history (including all sign-offs and committer/author credentials)

are identical. This is a huge security feature of git (and other SCMs that share this design feature)

这篇关于Git：如何对待提交，以便文件的版本全部存在（而不仅仅是差异）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！