git一覧

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

git-media を使ってみてちょっと妙な現象に出遭いました。
結論から言えば、コミット済みの未編集なバイナリファイルが変化してしまっているという状態です。
これについて、何が起こってしまったのかをちょっと調査してみた話を以下に記録しておきます。 続きを読む


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 だったからです。 続きを読む


Gitリポジトリに巨大ファイルを追加してみる

Git リポジトリってバイナリファイルが苦手(ソースコード類に比べれば)という話と、巨大なバイナリファイルがまずいという話が効いたことがあっので確認してみました。

確認した環境は Windows 上の 1.9.5-preview20141217 版の git と tortoiseGit でです。以下の内容は特に git vs tortoiseGit で差が無かったので、本体の問題(仕様)だと思います。

  • 600M くらいのバイナリファイルを追加
  • 2GB弱のバイナリファイルを追加
  • 4GB弱のバイナリファイルを追加

これでどうなるか、見てみました。 続きを読む


CentOS6.5 に Gitlab 7.13.1 をインストール

GitBucket にほしい機能があったのですが、 GitLab にはあるかなと思ったので久しぶりにインストールしてみることにしました。欲しい機能というのは、リポジトリの横断的な探索機能とか一覧機能とかです。メンバーで寄って集ってコードを置くような場所だと一覧や検索は欲しい機能です。

CentOS7ではあまりにシステム周りが変わっているようなので、手慣れている CentOS 6.5 でまずは試してみることにしました。
ちなみにインストールタイプは Minimal として設定しています。
定番の SELinux無効化 も行っておきます。

Gitの更新

CentOS 6.5 の yum で Git インストールすると今となっては古いバージョンなので比較的新しいバージョンを入れることにします。

新しい git のために、古い git でソースリポジトリを clone して make します

こんな感じでやろうとしたら git がまだ入っていなかったようなので、以下のようにしてもうまとめて実行(Minimalインストールだからだと思います)

これをやってから再び git の clone を実行してソース類を取得します。

なにやら途中でエラーが出たので、別のパッケージを追加

改めて make all を実行します。

インストールが終わったので古い方を削除

GitLab本体のインストール

昔は1つ1つ手作業でインストールおよび設定していて、大変な思いをした記憶がありますが、最近はパッケージ化されて随分とインストールしやすくなりました。公式のページにもその手順は書いてあるので、スムーズに入れることが出来ると思います。
以下の手順は公式ページのものほぼそのままだったりしますが、問題なくインストールすることが出来ました。

こんな感じとなります。回線がやや遅いようで、320M程度といってもそこそこの時間がかかります。

日本語化

日本語化パッチを作っている方がいらっしゃるのでそれも利用させてもらうことにしました。英語のまま使う場合にはこの手順は不要です。
現時点においては 7.9.4 までのバージョンに対応しているようなので、その範囲で日本語化を行えるような印象です。英語が直接コーディングされているようなので、バージョンが変更になるとうまく日本語化できない箇所も多くあるようです。

うまくパッチを当てられる部分だけあてるので、このあと Y や Enter 連打だったりします。

Gitlab起動

それでは以下のコマンドを実行して起動してみます。最初はそこそこ時間がかかります。

なんかエラーが出てしまったのですがもう1回実行してみます。

サーバーの IP アドレスをいれて最初の画面が出るか確認します。問題なければ以下のような画面が出ると思います。ここでデフォルト管理者のID/パスワードでログインします(この情報は公式ページを参照)

gitlab-home-7_13_1

gitlab-signin-7_13_1

まとめ。次回へ続く

長くなってきたので1回ここらで区切りとします。昔は大変だった GitLab のインストールも随分とやりやすくなりました。さすがにコンテナ1つ配備して終了できる GitBucket 並ではありませんが、手こずる部分はなくなったと言えると思います。
 次回は GitLab の操作や設定そのものをチェックしてみたいと思います。



Gitblit でユーザー認証をドメインサーバーに任せる

GitblitがQNAPで動作できたという記事を以前に書きましたが、GitblitはWindows上でも簡単に動かすことが出来ます。公式ページで Gitblit GO というパッケージを配布しており、ダウンロード後は中に入っているバッチファイルを実行するだけで、サービスのホスティングが可能となります。

このGitblitの認証は割とたくさんの方式をサポートしています。通常だと管理者が1つずつユーザーを追加する状態ですが、これをWindowsドメインに任せることができます。GitblitはLDAP認証をサポートしています。日本語での記事が見つからないようなので、記事にしてみました。

早速設定方法です。
gitblitを展開した中に、data/gitblit.properties という設定ファイルがあります。
この中の項目を書き換えていきます。

ウィンドウズドメインサーバー(LDAP)を使うための設定

LDAP用の設定

ここからは各自の環境に合わせて適宜変更してください。
ここではサーバーを 192.168.0.1 とし、ドメイン名を mydomain.com (ユーザーはMYDOMAINに参加)と仮定して設定方法を下記に示します。

ドメインの中を検索するユーザーとして、searchUser というユーザーを準備して、パスワードを password としておきます。

これらの設定をしたうえで、gitblitを起動し直して、ユーザーがログインしようとするとWindowsドメインに認証にいくと思います。
うまくいかない場合にはサーバーのアドレスや、usernameが間違っていないかチェックしてみて下さい。またユーザー名の前にはドメイン名を付加させることもお忘れ無く。

企業などで、細かくグループが分かれている場合には、accountBase, groupBase らを変更するだけでなく、
realm.ldap.bindpattern といった項目も変更が必要になるかもしれません。

問題点

試したバージョンが 1.6.0 です。この場合 LDAP認証されたユーザーはデフォルトで様々な権限を持たないようです。そのため、リポジトリの作成権限すらありませんのでちょっと使いづらいかもしれません。パブリックなリポジトリがあればそれらに対してコードの取得程度は出来るんでしょうが・・・。
このあたりは改善される気配があるので、様子見です。せめてグループ単位でデフォルトの設定を適用できるような改良が望まれます。


TortoiseGit で自分リポジトリを公開 その2

自分の作業用ローカルリポジトリでコード編集などしていて、中央サーバーにあげるまでもないが、他ユーザーに公開したいということがあります。前回はそれで git daemon の機能で公開を試みた、という感じだったのですが、ちょといまいちな結果で終わってしまいました。

結局公開用リポジトリを作業用PCに準備して、それを他ユーザーに公開する、という流れになるわけですが、作業用ローカルリポジトリ作成した段階ではどこからcloneしたわけでもなかったりするので、まずは作業用ローカルリポジトリから、公開用リポジトリを作成することが必要になってきます。

そのコマンドは以下のようになります。

これで作業用から公開用を作成することができます。
またこれと同じことを tortoiseGit でやるためには Clone メニューから下記のような感じで設定することでできます。

tortoisegit-clone

あとはこの公開用リポジトリパスを公開設定すればOKです。
Windowsなら、Windowsのファイル共有で公開してしまう方法が、楽だとおもいます。

受け取る側もこのWindowsファイル共有上でのファイルパス情報をもらって、cloneすることができます。
コマンドライン git でやる場合の注意点としては、パス区切りとしての円マーク(¥)を / を使わないといけないことでしょうか。tortoiseGitの場合には、このあたりはWindowsパス文字列で問題ないようです。

Linuxからアクセスするには

Windowsファイル共有で公開した場合には、Linux側でこのフォルダを cifs ファイル共有としてローカルにマウントしてしまうのがよいと思います。
このとき、rootのみファイル書き込み権限があるためにマウント時には少々オプションが必要になります。

パスワード制限されていたりするとユーザー名&パスワードの情報が必要になります。またマウント後、対象ディレクトリが書き込みできるかどうかパーミッションを確認しておくことが必要です。
問題が無ければ、このマウントしたパスから git clone することでリポジトリのcloneができます。ここまでできればpushもうまくできるようです。


TortoiseGit で自分リポジトリを公開(daemon機能)

約1年くらい前からgitを触り始めました。よくわからない状態から始めて、1人で黙々と機能を触っていただけだったのですが、ブランチ作ってコミット&プッシュ、Subversionとの連携として使うなどまではそれなりにやれるようになりました。
 最近Mercurialを使って作業をすることがあったのですが、この1年ほどのgitでの経験に色々と助けられた気がします。特にSubversion使用時の時の考え方から分散リポジトリ系への考え方への頭の切り替えが学習コストの大きいものだったと思います。

さて、Mercurial では自分のリポジトリを簡単に公開することが可能でした。TortoiseHg を使ってですが、ウェブサーバーの機能をGUI上から起動することができ、他のユーザーとのやりとりがすごく楽でした。恐ろしいことに公開したリポジトリ(しかも自分の作業用)は、他のユーザーからのPushも受け取ることができるという点です。これは設定次第でできることで、デフォルトは読み込みだけできるような制限付きで公開されます。

 同じことが Git でもできると便利だなと思ったので調べてみたのが今回の内容となります。

Gitでリポジトリ公開

これからの内容はWindows限定とします。また比較的新しいgit,tortoiseGit を使っている前提とします。

  • tortoiseGit 1.8.7
  • Git 1.8.5.2 (or 1.9.0)
  • Windows7 x64

こんな環境で試してみています。

さて「自分の作業用のリポジトリを今だけ公開する」というイメージで、リポジトリの公開設定をしてみます。先ほどのMercurialにおけるリポジトリの公開事例に近いことをやりたい、と考えてもらえればと思います。
このとき、作業リポジトリのフォルダどこかでtortoiseGitのメニューを開き、バックグラウンド稼働というメニューを選択します。すると、git daemonコマンドが実行されて公開状態となります。このとき git プロトコルが使用されて公開されます。

git-background

他の環境からは上記で公開されているリポジトリから clone や pull などで内容を取得することができるようになります。バックグラウンド稼働後に開くウィンドウで、 git://xxx.yyy.zzz.www/ というアドレスが表示されているかと思いますが、これがサーバーのアドレスとなります。
なお、英語表記モードのままGUIを使っている場合、このバックグラウンド稼働という項目は “Daemon” として表示されているのでご注意下さい。Background という項目では見当たらないので・・・。

注意事項

Windows上でこの公開を行うときには知っておくべき点があります。
まず Gitプロトコルですが、公式の説明にはこのように記載があります(Gitサーバープロトコル)。

次は Git プロトコルです。これは Git に標準で付属する特別なデーモンです。専用のポート (9418) をリスンし、SSH プロトコルと同様のサービスを提供しますが、認証は行いません。Git プロトコルを提供するリポジトリを準備するには、git-daemon-export-ok というファイルを作らなければなりません (このファイルがなければデーモンはサービスを提供しません)。ただ、このままでは一切セキュリティはありません。Git リポジトリをすべての人に開放し、クローンさせることができます。しかし、一般に、このプロトコルでプッシュさせることはありません。プッシュアクセスを認めることは可能です。しかし認証がないということは、その URL を知ってさえいればインターネット上の誰もがプロジェクトにプッシュできるということになります。これはありえない話だと言っても差し支えないでしょう。

このようにあるので、Pushアクセスを認めることができるかのようです・・・しかし、tortoiseGit のほうの説明にはこのようにあります(3.10. Daemon)。

Sometimes you want to quickly share you local repository to others without pushing to a remote git repository.

Caution
The selected repository is exported for read/write access without further authentication.

このために流し読みしていると read/write アクセスが必要である、という点だけ見てPushもできそうな気配を感じます。しかし最初の文章にあるとおり、リモートのリポジトリにPush無しという制限下で、という部分を忘れてはいけません。
 Windowsではこの方法を使う場合、他ユーザーへ読み取りのみの公開で使うという前提があるようです。これに気づかなくて色々と試行錯誤していました・・・。

テスト(その1)

うまくいかない組み合わせをメモしておきます。なかば自分のためです(笑)

Windowsクライアント Linuxクライアント
Linuxでgit://公開 NG NG
Windowsでgit://公開 NG NG

うまくいく組み合わせがあったように思いましたが、自分の作業リポジトリを公開する際にはどれでもダメなようです。

テスト(その2) 追記

うまくいかない組み合わせをメモしておきます。なかば自分のためです(笑)
うまくいった組み合わせがあったように思ったのでさらなる調査です。


前回と条件が違うのは、自分の作業リポジトリは公開しない、という点です。
作業用は公開しないが、別フォルダに作成した公開用のリポジトリを gitプロトコルで公開という状況です。
この別フォルダに用意した公開用のリポジトリは下記のコマンドで作成しています。

Windowsクライアント Linuxクライアント
Linuxでgit://公開 NG OK
Windowsでgit://公開 NG OK

このような結果となり、Windowsのgitクライアントでは失敗することがわかりました。このことからもgitプロトコル公開でPushさせる、というのは禁止事項にしておいた方が無難な気がします。


Windowsファイル共有でのGitリポジトリ運用

前回 QNAP のファイルサーバーで Git リポジトリを扱おうとして、思うようにいかなかったので他の方法を探してみました。
ちなみに、あれから git daemon による git リポジトリを扱う方法もやってみたのですが、Windowsのmsysgitのgitからは、Write Objects の状態から進まずという(フリーズ?)という状態で停止でした。

どうしてもファイルサーバー(NAS)上にリポジトリはおいておきたいので、方法を探した結果、Windowsのファイル共有でリポジトリを置く方法にトライしてみました。

構成

  • NASはWindowsファイル共有でリポジトリ用フォルダを公開
  • 他のWindows PCは上記のフォルダへアクセス可能。TortoiseGit を使用する

共有フォルダにリポジトリを作成

リポジトリを置く共有フォルダ(NAS上)で、リポジトリのフォルダを作成します。ここでは hello.git フォルダを作成しました。そして、そのフォルダを開いて、右クリックしてここにリポジトリを作成を選び、リポジトリ作成(bare)をします。
init-bare

リポジトリをクローンする

使用するPCで、上記のリポジトリからクローンします。ここでもまたTortoiseGitを使用しているとして、Gitクローンメニューを選択します。そして、URLでは先ほどの共有リポジトリのWindowsファイルパスを入力します。

例:\\FileServerName\repos_git\hello.git

今は初回のリポジトリ(ベアリポジトリ)のクローンのため、ワーニングが出ますが気にしないでおきます。

共有リポジトリへプッシュ(Push)

クローンしたフォルダで適当にファイルを追加して、Push までを確認してみたいと思います。
そのままPushを実行して問題ないはずです。もし失敗するようであればリモートの確認をしてみて下さい。

宛先のリモートが origin になっていると思いますが、その横の管理ボタンを押して、Git/リモートの項目内で origin を選択してみると情報が表示されます。このとき、URLに指定されているパスが Windowsファイル共有で指定したものと同じになっているかどうかを確認してみてください。またそのパスが有効な物であるか確認してみて下さい。

まとめ

Windowsだけで、しかもローカルで閉じているような環境の場合、このリポジトリ管理が一番楽なのかもという感想になりました。Web等で公開するリポジトリではこれはいけませんが、編集するマシンとしてデスクトップとノートPCがあり、さらにNASも運用している、という自宅環境ではアリな気がしています。