「 git-media 」一覧

Git LFS を使ってみる


Git はソースコードの管理ツールのため、巨大なバイナリファイルの扱いが苦手でした。これに対応すべく開発されたのが LFS: Large file storage という機能です。
今回はこれをインストール&触ってみたいと思います。なお環境はすでに git for windows がインストールされた環境で行っています。

ちなみにこの記事の内容は Git for windows 2.7.2, git-lfs 1.1.1 を用いての内容となってます。バージョンが異なる場合、以下の内容とは変更になっている可能性があるのでご注意ください。

GIT LFSについて

扱いとしては git のエクステンションという形になってます。
提供する機能は、指定されたファイルタイプの場合に特殊な処理を行うようになります。
この処理というのが、バイナリファイルを指し示すリンクをソースコードの場合と同じように保持するようにして、バイナリファイル自体はそのリポジトリとは別の場所に管理させる、というようなものです。

このLFSですが、前身になるようなものとして、git-media, git-fat などがありました。これらを使用していた人は同じようなものだと考えてもらってよいと思います。
LFSのメリットはすでにGitHub や、ほかのホスティングサービスも対応を始めているため、バイナリファイルの扱いに対して準標準を得られるのでは、というところもあるかと思います。

git lfs のインストール

https://git-lfs.github.com/ からインストーラーをダウンロードします。
この記事を書いているときには、 git-lfs-windows-1.1.1.exe でした。
このインストーラーをダブルクリックで起動してインストールを行っていきます。

インストールする場所ですが、 Git for windows をインストールしたフォルダで、
mingw64/bin 以下になるようにします。以下の図では標準の場所を指していますが、Git for Windows を別の場所にインストールしている場合ではここを修正する必要があります。
(現時点ではすでにインストールされているgit のインストールパスは探索されない模様)

インストールが終わって Git Bash を開き、以下のコマンドを実行します。

このように表示されればOKです。 git lfs init というコマンドもあったようですが、廃止扱いになっており、今は git lfs install が正しいようです。

動作を確認してみる

まずは適当な git リポジトリを用意して、動作を確認していきたいと思います。

Git lfs では LFS として管理させるファイルタイプを選択、設定します。
ここでは、よく使う画像ファイルを登録したいと思います。
この登録は以下のようなコマンドによって行います。

これらの情報は .gitattributes に格納されます。上記の実行結果で以下のようになっていました。

この .gitattributes ファイルを開かずとも、 git lfs track コマンドで確認することもできます。

さて登録したタイプにあうような適当なファイルをコミットしてみます。
ここでは png のファイルを追加・コミットしてみます。
以下のように行いましたが、これは通常の git のファイル追加・コミットと変わらないです。

これが LFS の管理になっているかどうかを確認するのに以下のコマンドを実行します。

正常に機能していれば上記のように、ファイル名とその何らかのハッシュ値が表示されます。

リモートリポジトリとのアクセス

ローカルでの機能確認ができたら、リモートとのアクセスを試してみたいと思います。
現時点では GitHub は、 1GB までは無料でLFSが使えるようなのでこちらを利用したいと思います。

GitHub で新規のリポジトリを作成し、そのリポジトリをリモートするように今回のリポジトリを設定しておきます。

そして普通に git push origin master を実行してみます。

というように普通に成功しました。
(ほかの設定も必要なのではと思っていましたので意外でした)

さて、正常にあがったところでこのリポジトリを別の場所で clone してみたいと思います。新規に取得してみることが目的なので、別PCでやってもかまいません。

内部的には追加したバイナリファイルは単なるテキストファイルに変わっています。
しかし、clone,pull などのコマンド実行の際には、LFSがうまく実行され、バイナリファイルが復元されます。

などと表示されている行がまさにバイナリファイルを取得している状態を示しています。

まとめ・感想など

準公式での巨大バイナリデータに対する対策が入ったことは大きいと思います。
最低限の LFS の動作を確認してきましたが、Git をコマンドで扱っている人にとってはすでに実用になるかなと思います。

tortoisegitとの組み合わせについて

1.8.16.0 のバージョンを使っている場合での話になりますが、ちょっとまずい点がありそうです。
「 TortoiseGit commit with git-lfs files, show me a error: “.git/index.lock” file exist」
というエラーがあるようで、これが 1.8.16.4 かそれ以降のバージョンで修正されるようです。

バイナリ状態がちょっと怪しい挙動

バイナリファイルを含むリポジトリを clone した際にバイナリファイルが復元されないケースがありました。このときファイルを試しにテキストエディタで開いたら以下のようになっていました。

このときバイナリデータの復元はどうするかというと、以下のコマンドによって復元(再取得)が行えます。

これによりデータが元のバイナリデータとして復元されます。

このような状態に陥っているときには、バイナリファイル復元した状態がすでに変更状態と見なされてしまうようで、最低限のデータ取り出しを行ったら、新規にリポジトリを作成・取得し直しといったことを行った方がよさそうでした。

対応プロトコルについて

Git LFSは大容量ファイルに対するサブのリポジトリを作ってそこにデータを放り込みます。このときの通信は http となるようで、前身の git-media のほうが対応種類が多くて状況によって適切に使い分けができた気がします。LFSもまた対応が広がってくれるとうれしいのですが。

LFSによる前提の崩壊?

従来からの使用者の感覚としては、ソースコードと大容量ファイル、それぞれ別管理という印象が強いですが、この機能が標準になってさえしまえば、これらをまとめた単位がリモートのリポジトリという1つのまとまりという認識に変わりそうです。
1つ気になった点としては、LFSリポジトリ(別の置き場を今はこう呼んでおきます)ができて、ここから必要なデータだけを復元するやり方によって、
開発者全員が全てのリポジトリデータのクローンを持つわけではなくなったと考えられます。
そのため、少々強引な表現ではありましたが「分散リポジトリだから開発者全員が同じリポジトリデータを持つ」は崩れてしまった前提になるのではないかなと感じます。
(そもそも公開されていないブランチもあるでしょうから、全員が同じリポジトリデータを持つわけではなく、単に公開されているものにおいては同じ、くらいなのですが)

LFSリポジトリデータ自体のクローンは行われないわけなので、ここにたまっているデータをきちんとバックアップしてあげる仕組みがないとトラブル時にバイナリを失ってしまうということになるのではと心配が残ります。

試しに適当な場所にリポジトリをcloneした後で、リモートリポジトリを削除し、ブランチの移動やら任意コミットへのcheckout を実行したところ、バイナリファイルの復元に失敗してしまうようでした。


git-media を使えるようにしてみた


オリジナルの git-media には以前に確認したような不具合が Windows 上で発生するため、そのままではバイナリが破壊されてしまうため使用に耐えませんでした。
今回 git-media を fork して、この問題を修正してみました。原因は簡単なことで改行コード変換がバイナリ取り出し時の処理に挟まってしまうことでした。

自分が修正した git-media はこちらに上げてあります。一応手元ではテストを行っていますが、動作を保証するモノではありません。普段の環境が Windows なので、 Windows の環境でのみテストしています。設定項目等も通常のものと変更はないです。

これで git を使っても、ひとまずは巨大バイナリに対して戦える状況になったかなと思っています。

git-media そのものの使い方は過去の記事を参考にしてもらえればと。

git-media はファイルシステムや scp, webdav が使える点がすごくいいと思ってます。これで送り込んだ先をバイナリ管理のリポジトリサーバーとしてバックアップ等含めてきちんと運用させるとよいかと思います。 続きを読む



git-media を使ってみる (2)


前回 git-media をインストールして動作をちょっと確認するところまで説明しました。
今回は以前に説明できなかった部分を見ていこうと思います。

git media sync について

巨大ファイルのハッシュから実体や、そもそも管理場所に送信する機能として git media sync を手作業で実行していました。
それは以下のような設定をしたからでした。

この autodownload を true に変更したらどうなるかを見てみます。
新規にファイルを追加して、add, commit した時点では変化がありませんでした。
しかし、Push を実行すると、・・・なんと挙動は従来のままかわりません!
設定項目の通り、ダウンロードのみに影響するようです。

この設定はリポジトリのチェックアウト時(ブランチの切り替え時とか)の挙動に影響してくるようです。
チェックアウト時に管理されている対象のファイルを、その外部の置き場からダウンロード(取得)してくるようになります。説明によると Pull 時にもこの設定は効いてくるようです。 続きを読む


git-media を使ってみる


git-media をインストールして使ってみます。Windows 環境にインストールして使っている事例がなかったのでちょっと手間取りました。

git-mediaとは

git-media とは巨大なバイナリファイルの扱いが苦手とされる git の拡張として作られたプラグインです。巨大なファイルにおいて、通常の git リポジトリに対してはファイルのハッシュ値を記録して、巨大なファイルの扱いに長けた別の場所にそのファイル実体を上げることが出来るようになります。
 こういった git のプラグインは他にもあって git annex とか有名(らしい)です。また最近の git には LFS( Large File Storage ) の拡張も出始めているので実は本内容はそのうち不要なものとなるかもしれません。

インストール

git-media では ruby スクリプトが使われているため、まずは Windows に Ruby を使えるようにするところからスタートです。
ここでは Ruby Installer (http://rubyinstaller.org/) を利用させてもらうことにしました。ここから 2.2.2 (32bit) を使用することにしました。32bit の理由は git 側が 32bit だったからです。 続きを読む