あなたはどのようにGitのバージョン管理にそれを知っていますか?(RPM)

概要:20分間、この記事を読みます

この記事は、記事では、神秘的な.gitディレクトリ下の文書の一部を説明し、gitのは、コンテンツに関連するデータ、およびgitのブランチを格納する方法を最終的に説明されている、ビットWebAppのアーキテクチャグループでの記事から再版されます。

 

 

データを格納する方法はgit:

 

ファイルシステムに保存されたフォルダオブジェクトの下に1 .gitフォルダには、いくつかのオブジェクトをgitの、彼らの名前が40ハッシュ値です、

分割されています。

  Bloblオブジェクトファイルオブジェクト
  ツリーオブジェクト・ツリー・オブジェクト
  インクルードは、オブジェクトをコミットコミット

 

2.コミットに対応するツリーオブジェクトによって提出のすべての内容を見つけることができます

  コミットオブジェクトを表示するにはgit logコマンド、オブジェクトの提出を通じて、あなたは木のオブジェクトレコードの上に取得することができます

 

gitのブランチ:

 

支店は、コミットの最新の枝に変数のポインタであります

 

1. .gitフォルダ、参考文献は、店舗関連のファイルは、ブランチをgitのフォルダ

ヘッドローカルブランチフォルダストアは、リモートブランチを格納するフォルダをリモコン、

 

2. .gitフォルダ電流検出ブランチを指すHEADファイルの下またはオブジェクトを提出します。

 

 

 

 

 

 

 

本体:

 

我々は別のブランチに切り替える、または提出し、指定歴史の記録に切り替えると、Gitはファイルのどのように歴史的なバージョンは、曲の外にありますか?言い換えれば:

  1. データはGitリポジトリに格納されている場合?
  2. ファイルの異なるバージョンを保存する方法は?
  3. これは、異なるバージョンを作成し、指定されたレコードの関連付けを送信する方法ですか?

いくつかのあいまいさを避けるために、開始する前に、最初のレコードの下に提出され、統一の理解:我々は、すべてのすべてのレコードは、GitのSHA-1アルゴリズムを使用して計算されるのみ40個の文字列の対応するものを提出しなければならないことを知っているが、当社の提出に基づいていますハッシュのうち。IDのこの40ビットのビット列は、チェックサムまたはハッシュ値または値またはSHA-1と呼ばれています。SHA-1は、ハッシュアルゴリズムがあるので、ここでは、この文字列が呼ばれて、下に統一されているハッシュ値を


 

データを保存する方法をGitリポジトリ

データを保存する方法をGitに、内部のディレクトリ.gitフォルダ内のメインのオブジェクトに答えます。ディレクトリオブジェクトかを説明しないように、のは何かの内側を見てみましょう。今、あなたは、Gitリポジトリを開く気軽にフォルダ内のファイルをオブジェクト(デフォルトでは、それは隠すことができる)1つの.gitディレクトリを見つけることができます。彼は次のようになります。


 

 

フォルダという名前の2つの文字がたくさんある、フォルダ番号は、ファイル名に38文字の文字列に数です。あなたは十分に敏感である場合、あなたはそれがコミットレコードを指定された同様のハッシュ値だと思うことができるかもしれません。  git cat-file  文書の内容を表示するためのコマンド。結果は以下の通りであります:
 

 

 

ここに示された結果は、私のプロジェクトのCHANGELOG.mdファイルの内容です。むしろ、それはCHANGELOG.mdが提出されたファイルの内容全体です。そして、オブジェクトフォルダは、Gitはデータを格納する場所です。

各コミットgitのは、名前をファイルに40ビットの列、オブジェクト上のフォルダの内容に基づいて算出したSHA-1アルゴリズムを使用して、ファイルが変更された存在でしょう。命名サブディレクトリのハッシュ値が、残りの38文字の最初の2つの文字がファイル名として使用されています。それは、あなたのファイルの変更が発生するたびに、そこに、対応するスナップショットに、ファイルのバージョンのすべての内容を保存しますです。あなたはGitリポジトリへの歴史的なバージョンをファイルを復元したい場合は、単に番目のバージョンに対応するファイルにハッシュ値を取得します。

しかし、どのようにファイルのGitのバージョンがコミットハッシュ値がそれであるときに該当するものを知っていますか?これは、Gitは異なるバージョンに関連付けられているとドキュメントアップを提出する方法ですか?

实际上在 objects 文件夹里主要存放着三类信息,除了我们上面提到的文件内容信息,还有文件路径信息以及提交信息。它们分别以 文件对象 blob object、树对象 tree object、提交对象 commit object 的形式存在。每一个对象都是 objects 目录下的一个文件,和保存文件内容信息的方式类似,Git 会通过 SHA-1 算法根据对象内容计算哈希值,得到一串 40 位的字符串为文件命名,用于找到他们。 接下来我们来看树对象和提交对象都包含了哪些内容。

当你提交时,Git 会把你当前的目录结构保存下来,对应的 tree object 结构如下:


 

 

包含了文件的文件名和文件对象的哈希值,以及子文件夹名字和对应的树对象哈希值。也就是说,你只需要找到某次提交根目录的树对象哈希值,就能找到该次提交所有文件对应的文件名以及文件对象哈希值。 也就能得到文件的历史版本内容了。

那我如何找到这个树对象?

就是通过我们最熟悉的提交对象。git log 命令可以找到对应提交的哈希值,我们可以看到提交对象的结构如下:


 

 

tree 指向的就是当前提交的树对象。parent 是上一次提交的提交对象。其他的是作者,提交人,时间和描述信息。

现在我就可以知道某次提交的某个文件的历史版本内容是什么了。由此我们也大概了解了 Git 是怎么存储文件的历史版本,又是怎么把历史版本和提交记录联系起来的。


 

 

```

当使用 git commit 进行提交操作时,Git 会先计算每一个子目录的哈希值,然后在 Git 仓库中将这些校验和保存为树对象。 随后,Git 便会创建一个提交对象,它除了包含作者,时间和描述信息外,还包含指向这个树对象(项目根目录)的哈希值以及上一次提交的哈希值。如此一来,Git 就可以在需要的时候重现此次保存的快照。
```

git 的分支

现在我们知道,只要拿到某次提交对象的哈希值,我们就能得到该次提交对应的快照。如果我们想要某个分支的文件内容,又是如何做到的?

分支只是一个可变的指针,指向分支最新的提交对象。

在 .git 里的 refs 文件夹中,保存了所有分支对应的最新提交对象的哈希值。目录结构如下:


 

 

其中 heads 文件夹保存的是本地分支,remotes 文件夹保存的是远程分支。以本地分支 master 为例,利用 cat master 可以看到,该文件中保存了最新提交对象的哈希值。如果你现在进行一次新的提交,会发现该文件中的内容会变为新提交对象的哈希值。

 

 

同时 Git 中有一个特殊的引用 HEAD,它总是指向当前检出的分支或提交对象。HEAD 指向的提交对象保存在 .git 里的 HEAD 文件中。 如下图,HEAD 指向了 master 分支。如果我们手动检出 master 分支的上一次提交,会发现该文件指向了一个确定的提交对象,即上一次提交的提交对象。

 

 

最后,可以用一张图来概括分支和提交对象之间的关系。

 

 

 

 
 

おすすめ

転載: www.cnblogs.com/eret9616/p/11694426.html