そもそもGitってなんや??

Gitは、従来よく使われていたCVSSVNなどのようなファイルのバージョン管理システムの一種です。このバージョン管理システムとは、主にシステム開発の際に、複数人でソースコードを編集する場合に、誰が・いつ・何を編集したかを記録し管理します。

バージョン管理システムの利便性は、それが無い場合を考えると理解しやすいと思います。

バージョン管理システムがない、尚且つ、共同開発である場合、各個人がそれぞれコーディング及び編集したソースコードは、何らかの共有ディスクに移すことになります。2人程度の場合ならば、それでも大丈夫かもしれません。しかしそれが、数十人、数百人となった場合はどうでしょうか? Aさんのコードを、Bさん が勝手に編集し上書き、次にCさんが編集中に、Dさんが上書きし、Cさんが編集を終え上書き・・・ これが数十人規模になると、とてもじゃないけど管理しきれませんね。そのような時に重宝するのが、Gitのようなバージョン管理システムです。

このGit、正確には分散型バージョン管理システムというタイプに分類されます。ちなみに、CVSやSVNは集中型バージョン管理システムです。ここでいう分散型とは、ソースコードをはじめとするプロジェクトのデータや編集履歴などの管理データ(リポジトリ)を各開発者のパソコン内に持てるということです。つまり、複数のリポジトリが分散的に存在するという意味です。

詳しくは、 Git – バージョン管理に関して または バージョン管理システム – Wikipedia  などを参照してください。

 

※この記事は、バージョン管理されていないローカルにある既存のプロジェクトから、Git環境を構築したときの記録です。

 

 

Gitの各種設定ファイル

Gitには、それぞれ有効範囲の異なる3タイプの設定ファイルが存在します。下にあるものほど優先順位が高くなります。

  • /etc/gitconfig
    • 全ユーザ・リポジトリに対する設定を行う
    • git config –system [設定値] により反映
    • Gitに対する共通設定などを行う
  • ~/.gitconfig
    • 特定ユーザの対する設定を行う
    • git config –global [設定値] により反映
    • ユーザー毎の共通設定を行う(ユーザ名やメルアドなど)
  • .git/config
    • 特定のリポジトリに対する設定を行う
    • この設定は最優先される
    • 管理から除外するファイルやリモートリポジトリへの接続情報、プロジェクト毎の動作設定を行う

 

 

 

ローカルリポジトリ(ノンベアリポジトリ)

SVNのような集中型バージョン管理システムでは、ソースの変更をコミットすると、即座にSVNサーバーにその変更内容が反映されるような仕様です。

一方、分散型のGitでは、コミット内容が反映されるのはローカル環境のリポジトリであるローカルリポジトリです。つまり、ある開発者がいくら滅茶苦茶なコミットをしようが、大本のデータ(後述する、リモートリポジトリ)には変化を与えません。Gitではプッシュという操作を行うことで初めて、大本のデータに変更を反映させることができます。

このローカルなリポジトリが、それぞれの開発者の環境に複数存在できるところが分散型の特徴といえます。リポジトリを分散することで、プロジェクトデータの消失する可能性がかなり減ります。なぜなら、大本のデータが何らかの理由で消失してしまっても、任意のローカルリポジトリから復元できるからです。

以下は、Gitローカルリポジトリのファイル構成例です。

  • WorkDirectory
    • file1
    • file2
    • directory1
      • file1_1
    • directory2
      • file2_1
      • file2_2
    • .git

.gitはリポジトリの実体であり、変更履歴や設定ファイルを含んでいるディレクトリです

※通常は、.git以外の全ファイルをGit追跡対象(管理対象)ファイルとします。

※WorkDirectoryは作業ディレクトリを表しており、名前は何でも構いません。

このように、ローカルリポジトリには作業ディレクトリというものがあり、そこに対してリポジトリを作成します。そして、そのディレクトリ内の任意のファイルをリポジトリに追加し、Gitの監視対象とします。

作業ディレクトリを伴うようなGitリポジトリをローカルリポジトリノンベアリポジトリといいます。ちなみに、ノンベア(none bare)とは「中身のある」という意味合いです。ここでいう中身とは、作業ディレクトリ内のファイルたちのことです。

以降の作業では、このリポジトリのことをローカルリポジトリと呼びます。

 

リモートリポジトリ(ベアリポジトリ)

もしかしたら正確には「リモートリポジトリ=ベアリポジトリ」ではないかもしれません。ただ少なくとも、ベアリポジトリであることはリモートリポジトリであるための必要条件なので、同義と見てもいいかなと思いました。

※↑実は裏技を使えばノンベアリポジトリ(作業ディレクトリを持つやつ)をリモートリポジトリとすることもできるようですが、ファイル管理という面では禁忌とも言える方法なので、見なかったことにします(詳細:git config –add receive.denyCurrentBranch ignoreはどう危険なのか

このリモートリポジトリは、Gitサーバー用のリポジトリです。リモートリポジトリはローカルリポジトリと違って、作業ディレクトリを持てません。つまり、このリポジトリでファイル変更やコミットなどの作業を行うことはできず、何処か別のリポジトリにプッシュ(変更内容をGitサーバに反映させること)することもありません。サーバー用というだけあって、非常に受動的なリポジトリです。

このリポジトリは、各開発者のローカルリポジトリの仲介役や中継点のような存在であることから、しばしば中間リポジトリとも呼ばれます。がしかし、以降ではリモートリポジトリとよびます。

ベアやノンベアよりもローカル、リモートのほうが分かりやすいですからね。

Gitをインストール(サーバー側)

Gitのインストール方法とインストール確認方法を下記に示します。下のようにバージョン情報が表示されれば、インストール済みであり、「コマンドが見つかりません」と出たら、インストールする必要があります。

# インストール済みの場合
git --version
git version 1.7.1

# インストールされてない場合
git --version
-bash: git: コマンドが見つかりません
# インストール方法
yum install git

 

Git操作専用ユーザの作成

既存のユーザが、Gitサーバにアクセスしクローンを作ったり、変更をPUSHしたりするのもいいかもしれない。ただ、それだとユーザ管理やセキュリティの観点から、あまりよろしくない。

よって、Git操作専用のユーザを作成し、全てのGit操作をこのユーザから行うことにします。

今回、Git操作専用ユーザには、通常のシェルへのログインは許可せず、Gitパッケージに付属しているgit-shellというGit操作のみに制限され た専用シェルをログインシェルとして指定する。また、パスワードは設定しない(設定する必要がない)。まず、su コマンドなどによるユーザ切替は、先ほどの専用シェルの指定によりできない。また、外部からのログイン自体もできないし、Git操作のためのSSH接続な どには公開鍵認証方式を使うのでパスワード自体必要ない。

※以降、「Git操作専用ユーザ」を、単に「Gitユーザ」という。

# Git操作に特化したユーザを追加する ※ユーザ名は任意
useradd -s /usr/bin/git-shell gitter

# 作成されたことを確認(ログインシェルも確認しておこう)
tail -1 /etc/passwd
gitter:x:504:504::/home/gitter:/usr/bin/git-shell

# 後で使うので .ssh ディレクトリを作っておく
mkdir /home/gitter/.ssh

# 755以下でないとだめ
chmod 700 /home/gitter/.ssh

 

既存のユーザにGit操作させるときの設定

基本的にGit関連の操作はGitユーザが行うものとする。ただ、それ以外の一般ユーザなどが、そのリポジトリで作業をすることがあるかもしれない。

ファイルの新規作成や、変更のコミット、プッシュやプルといった操作を行うかもしれないし、Webアプリケーション開発のような性格のリポジトリならば、 Webサーバに関わるシステムユーザ(apache、nginxなど)が関与することもあるだろう。また、Gitユーザ自体は通常のシェルへのログインを 許可してないので、一般的なシェル操作によるファイル作成やテスト的な作業ができない。

以上の理由から、Gitユーザ以外のユーザを仲間に加える方法を示す。

# 現在のユーザを gitter グループに所属させる
gpasswd -a [username] gitter

# umask値を確認しておく。 ※0002でないとマズイ
umask
0002

# umaskが0002で無い場合は以下の作業を行う(システムユーザなどの場合はその限りでない)
vim ~/.bashrc

# このユーザのumask値を再設定するため以下の行を追加
umask 0002
. ~/.bashrc # 設定を反映

 

※ユーザのグループ追加について

ユーザを特定のグループに追加する方法には「usermod -G user group」という方法もあります。しかしながらこの方法、確かにuserをgroupグループに所属させることはできますが、userが今まで所属していたグループ情報を全て上書きします(既存のグループ情報が消える)。なので、グループへのユーザ追加は基本的に gpasswd コマンドで行います。

※umask値について

umask値は、ファイルやディレクトリが作成されたときのデフォルトのパーミッションを示すものです。例えば、あるユーザのumask値が「002」のとき、新規作成されるファイルやディレクトリのパーミッションはそれぞれ次のようになります。

File → -rw-rw-r– = 664

Directory → drwxrwxr-x = 775

つまり、umask=002 の場合は、Otherの書込権限を無くすという意味になり、同様にして、umask=022 の場合は、GroupとOtherの書込権限を無くすという意味になります。

よって、ユーザのumaskが007以上の場合は、umask値を007未満に設定しなおす必要がある。普通、Otherにも読み取り権限は与える 002 に設定する。

※ホームディレクトリの無いシステムユーザのumask値を変更する場合

通常のログインユーザであれば、~/.bashrc で指定することでそのユーザのumask値を変更できます。しかし、システムユーザみたくホームディレクトリを持たないユーザの場合は、統一的なumaskの設定方法がありません。

というかよく把握していません・・・

そのため、それぞれのユーザによって設定方法が異なるので、適宜調べる必要がありそうです。

例えば、Webサーバーのnginxでは、「/etc/php-fpm.conf」に「umask 0002」の行を加えます。

 

 

リモートリポジトリ置き場を作成

# リモートリポジトリ配置用のディレクトリを作成
mkdir /opt/git

# パーミッションの確認
ls -ld /opt/git
drwxr-xr-x 4 root root 4096 X月 XX XX:XX XXXX /opt/git

※上の例では所有者及びグループがrootだが、Otherに読取+実行権限さえあれば所有者は誰でも良い。

 

共同作業用グループとパーミッション設定方法:

http://blog.onk164.net/archives/272.html

 

Gitリポジトリを作成する

Gitリポジトリを作成・・・といっても、冒頭に書いたように、「ローカルリポジトリ(ノンベアリポジトリ)」と「リモートリポジトリ(ベアリポジトリ)」の2つがあります。

そして、Gitを利用する状況や環境によって、Git環境構築の手順・方法が多少異なりますので、それぞれ ( ..)φ しておきたいと思います。

Gitを利用する状況や環境を大きく次の2つに分けました。これ以上の細分化は大変なので、適宜作業内容を流用して下さい。

※どちらも既存のプロジェクトフォルダにGitを適用する手順です

自前のGitサーバーで色々自由が利く場合

※ここでいう自前とは「自宅サーバー」だけのことではなくて、専用サーバーやVPS、クラウドサーバーなども含みます。

  • 既存のプロジェクトからリモートリポジトリを取得
    • ローカルリポジトリから –bare オプションをつけて、ベアリポジトリを作成
      • EclipseにEGitプラグインが入っていれば、「ベアリポジトリを作成」みたいなチェックボックスあるらしいので、それで対応可能と思われる
    • ベアリポジトリをGitサーバーへscpやsftpなどでアップロード
    • ※場合によっては初めのローカルリポジトリを作成する手順を省いて、プロジェクトから直接ベアリポジトリを取得して、サーバにアップしてもいい
  • リモートリポジトリから各クライアント上へリポジトリをクローンする
  • プロジェクトがGit化した!

 

GitHubを使う場合

  • 既存のプロジェクトからローカルリポジトリを取得
    • Linuxサーバ上のプロジェクトをGitコマンドでリポジトリに変換
    • Windowsクライアント上のプロジェクトをEclipseからリポジトリに変換
  • GitHubに新規リポジトリを作成する
  • 取得したローカルリポジトリをGitHubのリモートリポジトリにプッシュ
    • 接続プロトコルにhttpsを使うとプッシュできない!??
      • フツーにGitコマンドを使用した方法ではPushできました。GitHubがWebDAVに対応しているからでしょう。またGitHubアカウントのユーザ名とパスワードを要求されたので、EGitでも入力必須です。ただ入力したけど駄目だったが・・・
    • プッシュするためにはsshを使う必要があり、そのためにはssh公開鍵の登録が必要
      • http://logrepo.blogspot.jp/2010/09/github.html
  • プロジェクトがGit化した!

 

ではそれぞれの方法を詳しく見ていきます。

自前Gitサーバーで色々自由が利く場合

既存のプロジェクトからリモートリポジトリ取得

汎用的ではないですが、まずはよくありそうな、Eclipseのプロジェクトからリモートリポジトリを取得する方法です。この方法では、EclipseのEGitというプラグインを使ってリモートリポジトリ、つまりベアリポジトリを作成するので、特に他のプログラムはインスト不要で、GUI操作でOKなのでわかりやすいと思います。

EclipseのEclipseによるEclipseのためのベアリポジトリという訳ですね。

  • Gitパースペクティブを開く
  • 新規にGitリポジトリを作成する
  • ベアリポジトリオプションにチェックを入れる
  • ほにゃらら

これで、既存のEclipseプロジェクトからベアリポジトリが作成されました

 

次に別ケースとして、Eclipseからではなく、WindowsやMacなどにある任意のファイルからリモートリポジトリを得るための、汎用的な方法を説明します。というか、この方法が本来のやり方であり正攻法です。

まず、http://git-scm.com/downloads からGit本体をダウンロードしてインストールします。インストール方法は基本的にデフォルトのままNextしてけばいいと思います。

Git Bashを起動したら以下のコマンドを入力して、リポジトリを作成します。ちなみに、GitをインストールするとMinGWのように簡単なLinuxコマンドを使用できるようになります。


# 任意のプロジェクトディレクトリに移動
cd /path/to/project

# カレントディレクトリ(プロジェクト場所)のファイルからベアリポジトリを作成
# この例では、 /path/to というディレクトリ内に project.git というベアリポジトリが作成されます
# ベアリポジトリのディレクトリ名は慣例で .git で終わらせます
git init --bare /path/to/project.git

リモートリポジトリをサーバーにアップロード

リモートリポジトリ取得作業をサーバー上で行った場合には、この作業は不要です。

Eclipseで取得作業をした場合、ほぼほぼクライアントで作業したと思うので、サーバーにアップしましょう。サーバーへのアップ方法はなんでもいいです。

以下は、scpというコマンドを使った例です。

scp /path/to/project.git user@example.com:/path/to/server

 

 

GitHubを使う場合

 

ローカルリポジトリの取得(作成)

※この作成方法は、既存のプロジェクトやディレクトリから新規にGitリポジトリを取得する方法で、この他にも既存のGitリポジトリをクローン(複製)することでGitリポジトリをローカルに作成する方法もあります(後述のEclipseでの作業はこの方法)。

cd /path/to/dir

# .git というサブディレクトリが作成される
git init

# 所有者とグループをGitユーザに変更
chown -R gitter:gitter .

# グループに書き込み権限を与える
chmod -R g+w .

# 全「ディレクトリ」のみを対象にsetgid属性を与える
find . -type d -print0 | xargs -0 chmod g+s

# 全てのファイルを監視対象として追加
git add *

# 変更をコミットする ※masterブランチが作成される
git commit -m 'Commit massage'

※ .git にはリポジトリに必要なすべてのファイル (Git リポジトリのスケルトン) が格納される。

リモートリポジトリを取得する

Gitサーバとは、正確には中間リポジトリという位置付けであり、複数の開発メンバのローカル環境での作業を、統合するようなものである。これは、 bare-repository(共同作業の中継点として用いられる作業ディレクトリを持たない中間リポジトリ)を作成することで実現する。

では、既存のローカルリポジトリからリモートリポジトリを作成しましょう。

※以下の方法は、双方のリポジトリを同一マシン上に置くことを想定した場合である。

cd /path/to/workdir

# ローカルリポジトリからベアリポジトリを作成する
git clone --bare . /opt/git/workdir.git

cd /opt/git/workdir.git

# sharedオプションによってグループに書込み権限を与える+sgid付与
git init --bare --shared

# ベアリポジトリの所有者をgitterに変更
chown -R gitter:gitter .

# 所有者とグループ、及びsetgid属性を確認
ls -ld .
drwxrwsr-x 7 gitter gitter 4096 X月 XX XX:XX XXXX .

※リポジトリ名に関して、基本的には半角英数字でプロジェクト名を表すような名称をつける。

※ベアリポジトリ配置用のディレクトリの所有者はrootでもいい。ただし、otherに読み取り権限は与えること。

※今回の手順によるベアリポジトリ作成では、–shared オプションを付与して初期化しても、SetGIDが正しく設定されないようだ。というのも、既存のディレクトリやファイルは手動でSetGIDを設定しないと、設定が行き届かない。なので以下の方法から、再帰的にSetGIDを設定する。

[find . -type d -print0 | xargs -0 chmod g+s]

SetGIDを設定すると、そのディレクトリ以下のファイルやサブディレクトリのグループが自動的にそのグループになる(但し、所有者はファイル作成者になる)。

この時点で、Gitユーザである gitter 又は gitter グループに所属しているユーザで、尚且つ、SSHで接続できるユーザならば、Gitサーバからリポジトリをクローンしたり、逆にGitサーバへプッシュしたりできる。

ローカルリポジトリにリモートトラッキングを設定

ローカルリポジトリからベアリポジトリを作成したのはいいが、両リポジトリ間に直接的な関連はまだない。どういうことかというと、何処かのベアリポジトリから リポジトリをクローンしたならば、そのローカルリポジトリには、デフォルトでoriginという名前のクローン元のサーバが設定される。しかし、今回の場合は、ローカルリポジトリからベアリポジトリを作成した。そのため、元となったローカルリポジトリにリモート情報はまだ無いのである。

ローカルでの変更をローカル内で管理する分には、単なるコミット操作でいいのだが、その変更を共有したり公開したい場合は、ベアリポジトリへのプッシュという操作が必要になってくる。

Local Repository —- PUSH —> Bare Repository(Git server)

Local Repository <— PULL — Bare Repository(Git server)

ただ、その為にはリモートリポジトリのトラッキング(追跡)をする必要がある。でないと、どのようなベアリポジトリ(リモートリポジトリ)に対してプッシュすればいいのか、またプル及びフェッチすればいいのか分からない。具体的には、以下のような方法でリモートリポジトリを確認し、設定する。

cd /path/to/repository

# リモート情報の詳細を一覧表示
git remote -v

origin user@hostnamme:/path/to/repository.git (fetch)
origin user@hostnamme:/path/to/repository.git (push)

# 上のように表示されればいいが何も表示されない場合は以下の作業をする。
# リモートリポジトリを追加する
git remote add [remote_name] [remote URL]

# 確認
git remote -v
remote_name url (fetch)
remote_name url (push)

※追跡するリモートブランチが未設定の場合、前述のスクリプトではうまく動作しない。よって以下のことを確認する。

cd /path/to/repository
git remote -v # リモートリポジトリ名を確認
git branch -a # ブランチ一覧や現在のブランチを確認
vim .git/config # 以下のセクションが設定されているか確認
; ※remote_name=origin, branch_name=master とした場合の例
; ※ 特に、ブランチのセクションが設定されているか確認する
[remote "origin"]
url = /path/to/repository.git
fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
remote = origin
merge = refs/heads/maste

これで、少なくとも origin に対しては、フェッチ・プル・プッシュといった操作が可能となった。

 

Eclipseからベアリポジトリにアクセスする環境を設定

クライアント側でのキーペアの生成と配置

先ほどのユーザgitterにパスワードが付与されており、通常のパスワード認証によるSSH接続が許可された環境ならば、今すぐにでも、EclipseのEGitや他のクライアン トから、gitterとしてGitサーバのリポジトリにアクセスして、クローンをローカルに作成したり、変更をプッシュ(サーバに反映)したりできる。

しかし、今回の場合は、パスワードもつけてないし、SSHはパスワード認証を拒否している。よって、クライアント側でキーペアを作成し、公開鍵をサーバ側に登録することにする。

※ <user> 部分は適宜読み替えること

※以下はWindows上のMinGWでの作業です。

 

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/<user>/.ssh/id_rsa): /c/Users/<user>/.ssh/id_rsa
Enter passphrase (empty for no passphrase): 空エンター
Enter same passphrase again: 空エンター
・・・省略・・・

scp /c/Users/user/.ssh/id_rsa.pub <hostname>:/home/gitter/.ssh/ ← 公開鍵をサーバのgitterホームにコピーする

ssh [hostname]

Last login: Sun Aug xx xx:xx:xx xxxx from 1.1.1.1
CentOS release x.x (Final)

cd /home/gitter/.ssh/
# クライアント公開鍵を登録
cat id_rsa.pub >> authorized_keys

# パーミッションを変更
chmod 600 authorized_keys

# .ssh 以下の所有者を変更
chown -R gitter:gitter /home/gitter/.ssh/

Enter file in which to save the key: 鍵の置き場所を指定する

Enter passphras (enpty…略): 秘密鍵に対するパスフレーズを指定する ※今回はパスフレーズを設定しないので空エンター

<鍵の置き場所について>
Eclipseの都合上、鍵の場所はWindowsユーザーのホームディレクトリ下の .ssh に置く必要がある。あと、名前は「id_rsa」としておく。また、MinGWターミナルからWindows管理のフォルダにアクセスするときのパスの書 き方は、ちょっと変わっているので注意する必要がある。
パスフレーズを設定したいときは任意のものを指定して良い。これでEcliseのEGitからアクセスできるはず・・

Windows上のEcliseでの設定

ローカルリポジトリ置き場の指定

Gitサーバからリポジトリを複製するときに、デフォルトでローカルリポジトリが作成される場所を指定する。
Eclipse>設定>チーム>Git>デフォルト・リポジトリ・フォルダ に “${workspace_loc}” を設定
※ “${workspace_loc}” とはEclipseの変数でありワークスペースフォルダのパスを表している。

リポジトリ複製

(手順)

  • Gitパースペクティブ
  • Gitリポジトリーを複製し、このビューへ追加
  • Clone URI を選択に次に
  • URIに次を入力「ssh://gitter@sincere-hips.tokyo/opt/git/repository.git」
  • ブランチ選択では適当なブランチを選択
  • 完了

 

プロジェクトとしてインポート

通常、任意のディレクトリやファイルからローカルリポジトリを作成した場合、Eclipseのプロジェクトとしては認識されない(.projectファイルが無い)。

そのため、リポジトリをGitサーバから複製したら、手動で作業ディレクトリをEclipseのプロジェクトとしてインポートする。

(手順)

  • 複製したリポジトリを右クリック
  • プロジェクトのインポート
  • 一般的なプロジェクトとしてインポート
  • 適宜設定をした後に完了

リポジトリを選択し内容を更新して、作業ディレクトリを覗く。”.project”ファイルが作成されていることを確認。

 

Git環境に関する便利な設定をしておく

[Git Work Directory]/.git/config 又は <User Home>/.gitconfigに以下の項目を追加する。

[user]
name = コミットの際に用いられるユーザ名
email = コミットの際に用いられるメールアドレス

※ .git/config を編集すればリポジトリ単位で設定が反映され、 .gitconfig を編集すればユーザアカウント単位で反映される。

※ これは、git config [–global] user.name 等と同じ。

5.Eclipseからの変更(PUSH)をサーバ上のローカルリポジトリに反映する

任意のローカルリポジトリを用意する

すでにサーバ上のローカルリポジトリがあるならばそれを使う。無い場合は新規に作成してもいいのだが、そもそも今回の場合、Gitサーバを用意する手順と して、「任意のディレクトリからローカルリポジトリを作成→そのローカルリポジトリからGitサーバ用のベアリポジトリを作成」という手順を踏んだので、 ローカルリポジトリが無いわけがない・・・

フックするためのサーバサイドスクリプトを編集する

  • クライアントサイドのフックスクリプト
    • pre-commit: コミット処理を行う前に実行され、コミット内容(コード等)のチェックなどに利用される。
    • post-commit: コミット処理が終了した後に実行され、何らかの通知などに利用される。
    • prepare-commit-msg: コミットメッセージエディターが起動する前に実行され、デフォルトメッセージを編集できる。
  • サーバサイドのフックスクリプト
    • pre-receive: pushを感知したときに実行され、0以外の値で終了させるとpush自体を却下する。
    • post-receive: push処理が終了した後に実行され、push後の処理や作業を記述する。

などなど、上記以外にも、その他多数のフックスクリプトがあるので、詳細は下記リンク参照のこと。

Git のカスタマイズ – Git フック

 

<Gitユーザのumask値の確認>
フックスクリプトを作成する前に、先にGitユーザのumask値を確認しておく。umask値については、先に書いた通り。

当VPSの環境では、uidが200未満のユーザのumask値は「022」で、200以上のユーザのumask値は「002」となっているようだ。Gitユーザ(gitter)のuidは200以上であるため、たぶん umask=002 になっているはずだが・・・
確認の為に、Gitサーバのフックスクリプトを以下のように変更する。


> vim /opt/git/workdir.git/hooks/post-receive

#!/bin/sh

# Git接続ユーザのumask確認のためのコマンド(確認済みなら消してもいい)
umask

# ローカルリポジトリの作業ディレクトリへのパスを指定
REPOSITORY=/path/to/repository
REMOTE_NAME=origin

# --git-dir にはカレントディレクトリからGitリポジトリへの相対パスを指定する
CMD1="umask 002"
CMD2="cd $LOCAL_REPOSITORY"
CMD3="git --git-dir=.git pull $REMOTE_NAME"
$CMD1 && $CMD2 && $CMD3

Eclipseからファイル編集→コミット→プッシュ したときに表示されるメッセージが「002」となっていればOKだが、「022」の場合はグループの書込み権限が無い状態なので、以下のような修正が必要。※「002」ならば、CMD1 の部分は不要。

 

 

▼Gitユーザの識別情報を設定


CMD3="git --git-dir=.git pull $REMOTE_NAME"
$CMD1 && $CMD2 &&

> sudo -u gitter git config --global user.name "gitter"
> sudo -u gitter git config --global user.email gitter@domain.me

# 設定の確認
> less /home/gitter/.gitconfig

[user]
name = gitter
email = gitter@sincere-hips.tokyo

※ sudo -u username というように実行ユーザを指定しないと、現在のユーザのホームディレクトリ下に .gitconfig が作成されてしまうので要注意です。

※ 自動的なマージ作業などはGitユーザが行うのだが、この識別情報を設定しないとそれができない。

 

動作確認

(手順)

  • Eclipse上でファイル編集
  • コミット
  • プッシュ
  • エラーメッセージが表示されないことを確認 ※エラーが表示された場合は、サーバ上のローカルリポジトリの所有者やパーミッションを確認する。
  • フック対象のローカルリポジトリを調べて、Eclipse上の変更がちゃんと反映されているか確認