このシリーズの最初の6つの文章を通じて、Gitを使用してテキストファイルのバージョン管理を行うことを学びました。バイナリファイルもありますが、バージョン管理もできますか?答えは肯定的で、Gitはすでにマルチメディアファイルのようなバイナリ大オブジェクトブロック(blob)を処理できる拡張子を持っている。そこで、今日はGitを使っていわゆるバイナリ資産を管理することを学びます。

Gitが大きなバイナリオブジェクトファイルをうまくサポートしていないことが認められているようです。バイナリ・オブジェクトは、大きなテキスト・ファイルとは異なることを覚えておいてください。Gitは大規模なテキストファイルのバージョン管理に問題はありませんが、不透明なバイナリファイルにはあまり役に立たず、大きなエンティティブラックボックスとして提出するしかありません。

このようなシーンを想定すると、別の人が興奮している第一人称解読ゲームがあり、複雑な3 Dモデリングを作成しています。ソースファイルはバイナリ形式で保存され、最後に1 GBサイズのファイルが生成されます。Gitソースウェアハウス履歴に1 GBサイズの新規コミットが1回コミットされました。その後、モデルの人物の髪の造形を修正して更新を提出します。Gitは頭やモデルの残りの部分から髪を離れることができないので、1 GBの量しか提出できません。次に、モデルの目の色を変更して、この部分の更新を提出します:またGB級の提出量です。1つのモデルに対するいくつかの微小な修正は,3 GB級のコミット量をもたらす.1つのゲームのすべてのリソースをバージョン管理したいという規模については、深刻な問題です。

異なるのはobjのようなフォーマットのテキストファイルであり、他のタイプのファイルと同様に、objファイルがモデルを記述する一連の純粋なテキスト行である場合とは異なり、すべての更新変更状態をコミットして格納する。モデルを修正してobjファイルに保存すると、Gitは2つのファイルを行ごとに読み取り、差分バージョンを作成してかなりのコミットを得ることができます。モデルが細かくなればなるほど、コミットは小さくなります。これが標準的なGitの例です。ファイル自体は大きいが、Gitは上書きまたは疎ストレージの方法を使用して現在のデータ使用状態の完全な説明を構築する。

しかし、すべてが純粋なテキストであるわけではありませんが、Gitを使用するので、解決策が必要で、いくつか現れています。

OSTreeは、オペレーティングシステムのバイナリファイルを管理するためにGNOMEプロジェクトとして登場しました。ここには適用されないので、直接スキップします。

Git大ファイルストレージ(LFS)は、Git Hub上に置かれたオープンソースプロジェクトであり、git-mediaプロジェクトから分岐している。git-mediaとgit-annexはGitが大きなファイルを管理するための拡張です。これらは同じ問題に対する2つの異なる解決策であり,それぞれ利点がある。公式のプロジェクトではありませんが、私から見れば、それぞれユニークな点があります。

これらについて、git-mediaとgit-annexを生産に使用しました。では、その動作原理を説明します。

git-mediaはRuby言語で開発されているので、まずgem(LCTT訳注:GemはRubyベースのいくつかの開発ツールパッケージ)をインストールします。インストールの説明は、Webサイトにあります。git-meidaを使用するユーザーは、gemがプラットフォームにまたがるツールであるため、各プラットフォームで適用される必要があります。

git-mediaのインストールが完了したら、Gitの構成オプションを設定する必要があります。各マシンに一度だけ配置する必要があります。

$git config filter.media.clean "git-media filter-clean"
$ git config filter.media.smudge "git-media filter-smudge"

git-mediaを使用する各リポジトリで、作成したフィルタをメディアに分類するファイルタイプに結合するプロパティを設定します。このような用語に混同されてはいけない。より良い用語は「アセット」です。メディアは通常、オーディオ、ビデオ、写真を意味しますが、3 Dモデル、ベイク処理、テクスチャなどをメディアとして簡単に分類することができます。

例:

$ echo "*.mp4 filter=media -crlf" >> .gitattributes
$ echo "*.mkv filter=media -crlf" >> .gitattributes
$ echo "*.wav filter=media -crlf" >> .gitattributes
$ echo "*.flac filter=media -crlf" >> .gitattributes
$ echo "*.kra filter=media -crlf" >> .gitattributes

サーバにGitソースウェアハウスが既に存在すると仮定し、最後のステップでソースウェアハウスの「母艦」が存在する場所、すなわち、メディアファイルがすべてのユーザ共有にプッシュされると、メディアファイルが格納される場所をソースウェアハウスに伝える。これは倉庫のgit/configファイルで設定されています。ユーザー名、ホスト、パスに置き換えてください。

[git-media]
transport = scp
autodownload = false #默认为 true，拉取资源
scpuser = seth
scphost = example.com
scppath = /opt/jupiter.git

サーバ上のSSH設定が複雑な場合、たとえば非標準ポートまたは非デフォルトSSHキーファイルのパスを使用している場合は、ssh/configを使用してホストのデフォルト構成を設定します。

git-mediaの使用は通常ファイルと同様に、通常ファイルとblobファイルを同じように扱うことができ、commit操作を行うことができます。操作プロセスの唯一の違いは、資産(またはメディア)を共有リポジトリに同期する必要がある場合です。

チームの資産または自己バックアップ資料を公開する場合は、次のコマンドを使用します。

$ git media sync

git-mediaのファイルを変更後のバージョンで置き換える場合(たとえば、美声化されたオーディオファイル、または完了したマスクペイント、または色に階層化されたビデオファイル)、Gitにメディアを更新するように明確に伝える必要があります。これはgit-mediaがリモートですでに存在するファイルのデフォルト設定をコピーしないことを上書きします。

$ git update-index --really-refresh

チームの他のメンバー(またはご本人、他のマシン)がこのウェアハウスをクローン化している場合、git/configでautodownloadオプションをtrueに設定していない場合は、デフォルトではリソースはダウンロードされません。しかしgit-mediaの同期コマンドgit media syncは、すべての問題を解決します。

git-annexの処理フローはやや異なり、デフォルトではローカル倉庫を使用していますが、基本的な考え方は同じです。リリース版のソフトウェアウェアハウスからgit-annexをインストールするか、必要に応じてこのサイトからインストールをダウンロードできます。git-mediaと同様にgit-annexを使用するユーザーは、そのマシンにインストールする必要があります。

git-mediaよりも初期化設定が簡単です。次のコマンドを実行して、パスに置き換えると、サーバに裸のリポジトリを作成できます。

$ git init --bare --shared /opt/jupiter.git

ローカルコンピュータにクローンしgit-annexの初期パスとしてマークします。

$ git clone [email protected]:/opt/jupiter.clone
Cloning into 'jupiter.clone'... 
warning: You appear to have clonedan empty repository. 
Checking connectivity... done.
$ git annex init "seth workstation" 
init seth workstation ok

フィルタを使用してメディアリソースまたは大ファイルを区別するのではなく、git annexコマンドを使用して大ファイルの分類を構成できます。

$ git annex add bigblobfile.flac
add bigblobfile.flac
(checksum) ok
(Recording state in Git...)

通常のファイルと同様にコミット操作を行います。

$ git commit -m 'added flac source for sound fx'

しかし、git annexは自分のブランチを使用して資産を追跡するため、プッシュ操作は異なります。リポジトリの管理方法に応じて、最初のプッシュには-uオプションが必要です。

$ git push -u origin master git-annex
To [email protected]:/opt/jupiter.git
* [new branch] master -> master
* [new branch] git-annex -> git-annex

git-mediaと同様に、通常のgit pushコマンドはサーバにデータをコピーしません。関連するメッセージを送信しただけです。ファイルを本当に共有するには、同期コマンドを実行する必要があります。

$ git annex sync --content

人はすでに共有リソースをコミットしています。それを引き出す必要があります。git annex syncコマンドでは、ローカルでローカルにホストが存在しないが、サーバに存在するリソースをチェックアウトするよう求められます。

git-mediaとgit-annexは非常に柔軟で、サーバの代わりにローカル・リポジトリを使用することができるため、プライベートなローカル・プロジェクトの管理にもよく使用されます。

Gitは非常に強力で拡張性の高いシステムアプリケーションであり、ためらうことなく使用するべきです。今からやってみよう!