「 git 」一覧



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 を実行したところ、バイナリファイルの復元に失敗してしまうようでした。


TortoiseGit で git add -p 相当できた


git には部分コミットを行う機能があります。これがコマンドでは git add -p ですが、 TortoiseGit からもこれと同じことが実現できることがわかったので記録しておきます。

まずは以下のように題材となるデータを用意してみました。
ある要求に対応するコードを実装したものの、途中で発見したバグを同時に直してしまったというケースです。このような場合にはバグ修正と機能追加といったように2つのコミットに分割するのが正しいです。

git-add-1

続きを読む


Linux でも使える Git の GUIクライアント


git 操作はコンソールで行うのが一番確実で柔軟に対応できるのですが、GUIがあっても損ではないので調べてみました。ただ実用的に使えるかどうかまでは調べていませんのでご注意ください。

Gitk
本家定番のツール。これで出来ないこともないけれど他のツールのほうが優れているならそちらを使用したい。

GitForce
WindowsとLinuxに対してツールを提供している。
ぱっと見たところログのグラフが無いようなのでつらいかも。

QGit
2007年で開発停止。スクリーンショットを見る限りでは普通。

git-cola
Windows, Mac, Linux(archlinux,debian,fedora,gentoo,ubuntu,opensuse) と対応範囲が広い。Pythonで実装されている模様。
スクリーンショットを見る限りこれは検討するに値しそう。

tig
text mode interface for git ということらしい。GUIではないけれど、git のコマンドラインラッパーということで。
単純なコマンドたたきはつらいが、これなら使える気にさせてくれるかも。

Giggle
開発が停止している模様.こちらもログの描画はそれなりに出来る模様。

git-cola を試してみる

インストール

Fedora23 で試したときには以下のコマンドを実行しました。

起動

git-cola とタイプすれば起動します。即座にはコードのコミットを行うモードとなっているようです。

コミット要約のテキストボックスと、コミット詳細のそれぞれのメッセージを入力する部分が独立しているので、コミットメッセージの書き方をある程度整えることが出来そうです。
またこの画面でメニューから項目を選ぶことでリポジトリ操作が可能なようになっていました。

git-cola-1

グラフィカルな履歴を見る場合には、メニューから “View/DAG” と選択します。
コマンドラインで直接 git-dag とタイプしても起動できるようです。

git-cola-2
複数のブランチを集約してグラフ化する方法はちょっと見つけられませんでした。
コミットログの確認の部分がやりにくいため、自分のスタイルには合わなさそうでした。ただログを確認せずガンガン進むような人は扱いやすいのかもしれません。

tig を試してみる

tig: text mode interface for git を試してみます。
最初の感想としてはこれは常用アリかなと思っています。CUIだけどマウス操作もちょっとできたりして驚きです。

インストール

Fedora23 で試したときには以下のコマンドを実行しました。

起動

実行するには tig とタイプします。デフォルトではカレントブランチの情報しか出ないため、すべてを表示するには “–all” オプションを使用します。

起動すると以下のようになります。コミットログを確認するモードで立ち上がりました。

git-tig-1

ブランチへの派生グラフがスラッシュ、バックスラッシュを使わない描画のためか、自分には割とこれが見やすかったりします。

git らしくコミットのフェーズがステージング、コミットと分かれた方法になっています。
ステータスビュー(“S”)に切り替えた後、コミット対象を”u” で選んで、”C”(Shift+s) でコミットメッセージ入力となります。

これらのヘルプを確認するには、”h” となっています。

git-tig-2
いくつか機能としては足りていない部分があり、たとえばブランチの切り替えはこのツールでは見当たらない感じだったので、git コマンドを操作することになりそうです。
ただ設定ファイル(.tigrc) で拡張コマンドを定義できたりデフォルトの設定を変えたりと柔軟なことが出来そうだったので、カスタマイズをちゃんと行えば出来る範囲は広がっていくものと思われます。

その他

カーソルキーではビューの移動になってしまい、スクロール関連に戸惑いました。
アクティブのビューでのページスクロールは PageUp/Down で、1行単位での行スクロールは、”j”, “k” となっています。
git add -p のように部分的な変更をステージングへ登録する際にはこれも使用することになります。行を選択して “u” で、その部分をステージング登録できます。
これは git add -p を直接実行するよりは使い勝手がよいと感じています。

git-tig-3

まとめ

とりあえず gitk を卒業して tig で Linux での git 生活を始めてみようと思います。


git subrepo を試してみた(が失敗)


git で submodule でもなく、 subtree でもなく、両方の良いところ取りを狙った subrepo というものの存在を教えてもらったので早速試してみました。subrepo は割と新しい bash を期待しているようだったので、 Git for Windows の 2.5.1 を用いて試してみました。

ちなみに従来の msysgit の Git Bash だと clone する際に既にエラーになるようでしたが、新しい MinGW のほうではうまく clone できました。
ただしシンボリックの扱いの部分でうまく動かないようだったのでそこだけは手動で変更して対処してみました。

とりあえずこれで git subrepo version とやってみたところ以下のように表示されたところまで確認できました。

これでようやく別リポジトリをサブリポジトリとして取り込むところまでは動作を確認出来ましたが、取り込んだ先での編集を元のリポジトリに Push することができないという問題に出遭ってしまったためにまだまだ安定して使えないという印象です。これについては Issue にも上がっているようだったので、近いうちに修正されると良いなと思っております。
コマンドの体系が割と理解しやすいため、うまく動くようなら subtree よりはこちらを使いたいと思います。

今後に期待といったところですね。その時にはちゃんとまとめて再び記事にしたいと思います。


Windows の Git は Git for Windows で!


Windowsで Git というと、 msysgit が定番でしたが、どうやら 1.x 系を持って終了のようです。
https://msysgit.github.com/ へアクセスすると、 https://git-for-windows.github.io/ へアクセスがリダイレクトされました。
そして https://github.com/msysgit/git にてリポジトリの状態を確認してみようとしたら、冒頭に、「msysGit-based Git for Windows 1.x is now superseded by Git for Windows 2.x」という記述があります。

ということで、 Git for Windows がこれからの標準の Git となるようです。そしてこれを早速インストールしてみました。
基本的なインストール方法は全く変わりませんが、ターミナルが mintty になったり bash のバージョンが上がったりと割と最近のものへ更新されているようです。

そんな中以前は内包している Subversion のモジュールが 1.4 系と古かったこともあり、 git-svn を使う場合に不安がありました。
今回の更新ではそのあたりがどうなっているかを確認してみたいと思います。

ということで 内部で使用する Subversion モジュールのバージョンも 1.8系へと更新されました。これで git-svn を使う際にも安心ですね。
ちなみに今回の Git のバージョンは、 2.5.1 となってました。

その他、気になったところとしては、まだ日が浅いためか使用者が少ないためか、 Push しようとすると Norton Internet Security が通信どうする?と聞いてきました。これはそのうち落ち着くことでしょう。(たぶん)


git-fat を使ってみる


git-media の状態がまずかったので、似たようなソリューションを探してみたところ git-fat というものが見つかりました。これは git-media からフォークして作成したもののようです。言語が Ruby から Python へと変化していましたが。
 今回は Windows 環境にてこの git-fat をインストールして動作を確認するところまでやってみます。

インストール

git-fat は Python 2.x 系を必要とするようです。そのためまずは Python をインストールします。今回 Windows のインストーラー付きの Python は 2.7.10 を使用しました。インストールした Python にはパスが通っていることとします。
 その後、コンソールで以下のコマンドで git-fat をインストールすることが出来ます。

既にパッケージ化されているようでインストールは非常に簡単です。 続きを読む


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


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

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

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

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

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


git-annex を Windowsにて実験してみた


Git LFS が進んでいるようですが、 git-annex を実験してみました。git-annex はまだ Windows の環境でベータ扱いのようですが…。あまり日本語の記事もなく、手探りで色々と試してみましたが、以下の内容は間違っている可能性があるのでご注意ください。

公式サイトのほうからは Windows のインストーラーが公開されています。これをインストールして使用してみました。自分の環境では、うまくパスが通らなかったため、git-annex が配置された場所に手動でパスを通して動くように変更しています。
その後、公式ページの walkthrough にあった以下のようなコマンドを実行してみました. 続きを読む