さくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub

2012年6月3日 2 開発 , , , , ,

さくらのVPS(v3) 2GB プランへの環境構築メモ 10。今回は Git 関連について書く。

シリーズまとめ – さくらのVPS を改めて使いはじめる

もくじ

Git

後述する作業のため Git 環境を整える。

さくらのVPS(v3) の CentOS だと初めから Git が入っているらしく、このシリーズでも既に何度か利用している。パッケージ版なので yum update により更新されている可能性もあるが、念のためどんなバージョンが入っているか確認。

$ git --version
git version 1.7.1

すこし古いけど現時点の最新版である 1.7.10 と同じ 1.7 系なのでよしとする。

次は Git のリポジトリ ルートを作成する。GitHub や Gitolite のリポジトリからミラーリングしたり Redmine から参照する Git リポジトリはここへ置く。

$ sudo mkdir /var/lib/git

VPS 上で開発しないなら不要かもしれないが Git 自体の設定もおこなう。git config –list で現在の Git 設定が出力される。何もしていないなら以下のようにエラーとなるはず。

$ git config --list
fatal: error processing config file(s)

設定を追加。まずはユーザーと、その識別に使用されるメールアドレス

$ git config --global user.name XXXX
$ git config --global user.email XXXX@example.com

次にカラー設定。VPS 上で Diff を見る場合などに有用。

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global color.interactive auto

設定を確認。

$ git config --list
user.name=XXXX
user.email=XXXX@example.com
color.diff=auto
color.status=auto
color.branch=auto

ばっちり。

Gitolite のセットアップ

VPS 上へ Git のリモートリポジトリを構築するために Gitolite を導入する。このツールについては、以下の記事がわかりやすい。

SSH 接続用の鍵と設定ファイル作成

ローカルマシン上で VPS 上の Gitolite へ SSH 接続するための鍵ファイルを作成する。作成方法については前述の記事かこのシリーズ第一回の「SSH 接続用の鍵を作成する」あたりを参考のこと。

ここでは、パスフレーズなしで秘密鍵 gitolite と、公開鍵 gitolite.pub を作成したものとする。

鍵ファイルを作成したらローカルのユーザー HOME 直下にある .ssh ディレクトリ内に移動させる。Windows Vista/7 なら C:\User\ユーザー名.ssh、Mac OS X や Linux なら ~/.ssh になるはず。

.ssh フォルダがなければ作成しておく。Windows の場合、Explorer からだと . で始まるフォルダは作成できないのでコマンドプロンプトから mkdir を実行すること。

鍵ファイルを .ssh フォルダに移動したら同じ場所に config という名前 ( 拡張子はなし ) のテキスト ファイルを作成する。このファイルは Windows なら msysGitGit Extensions、Mac ならターミナルからの SSH で参照される。

ファイルを作成したら以下の内容を記述して保存する。example.com となっている部分は自分の VPS に割り当てているドメイン名か IP アドレス、PORT の XXXX には SSH 接続するときのポート番号を数字で指定する。すでに config ファイルが存在する場合は、その中の末尾に追記しておく。

HOST gitolite.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite

それぞれの設定項目の意味は以下のようになる。

設定 内容
HOST 接続設定の識別子。次に host という名前が出現するまでが、ひとつの設定となる。git コマンドなどで接続先にこれを指定すると、以降の内容が使用される。複数の接続設定を記述する場合は、重複しないようにすること。
HOSTNAME 接続先となるホスト名。サーバーのドメイン名、または IP アドレスを指定する。
USER 接続先でログインするサーバー上のユーザー名。今回は VPS 上に gituser という Gitolite 管理用ユーザーを作成するので、その名前を指定している。
PORT SSH 接続に使用するポート番号。デフォルトは 22。もしポート番号を変更しているなら、その番号を指定する。
IDENTITYFILE 接続に使用する秘密鍵ファイルへのパス。~ ( チルダ ) はローカルマシン上のユーザー HOME を表す。

詳細は以下を参照のこと。

ここまでの作業で .ssh フォルダには以下のファイルがそろったはず。

ファイル 内容
gitolite 秘密鍵ファイル。ローカルマシンから VPS 上の Gitolite へ接続するために使用する。
gitolite.pub 公開鍵ファイル。VPS 上の Gitolite が使用する。
config SSH 接続用の設定ファイル。

最後に公開鍵ファイルを VPS 上にアップロードする。

Windows なら Tera Term や WinSCP、Mac の場合はターミナルから scp コマンドを実行する。ここではいつも VPS 上でログインしているユーザーの HOME 直下gitolite.pub という公開鍵ファイルを転送したものとする。

Gitolite 管理用ユーザーの作成

VPS 上に Gitolite の管理用ユーザーを作成する。名前は gituser としておく。

$ sudo useradd --shell /bin/bash --home /home/gituser gituser

アップロードしておいた SSH 接続用の公開鍵を gituser の HOME へ移動して所有者とパーミッションを変更。

$ cd
$ sudo mv gitolite.pub /home/gituser
$ sudo chown gituser:gituser /home/gituser/gitolite.pub
$ sudo chmod 644 /home/gituser/gitolite.pub

念のためファイルを確認。

$ sudo ls -l /home/gituser/
合計 4
-rw-r--r-- 1 gituser gituser 390  5月  26 08:43 2012 gitolite.pub

ばっちり。

Gitolite のインストールと初期設定

準備が整ったので Gitolite をセットアップする。まずはインストールから。さくらのVPS(v3) の CentOS なら yum から入れられる。

$ sudo yum install gitolite
... 中略
Running Transaction
  Installing : 4:perl-Time-HiRes-1.9721-119.el6_1.1.x86_64                                                            1/2
  Installing : gitolite-2.3-2.el6.noarch                                                                              2/2

Installed:
  gitolite.noarch 0:2.3-2.el6

Dependency Installed:
  perl-Time-HiRes.x86_64 4:1.9721-119.el6_1.1

Complete!

バージョンは現時点で 2.3.2。依存モジュールとして Perl 用の高精度タイマーもインストールされたようだ。

次は Gitoite の初期化。

ユーザーを gituser に変更してから、gl-setup コマンドに公開鍵ファイルを指定して実行する。途中、hit enter… と表示されたら Enter キーを押す。すると自動的に vi で Gitolite の設定ファイルが開く。特に変更することはないので :q を入力したあと Enter キーを押して、そのまま終了しておく。

$ sudo su - gituser
$ gl-setup gitolite.pub
The default settings in the rc file (/home/gituser/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.

hit enter...
creating gitolite-admin...
Initialized empty Git repository in /home/gituser/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /home/gituser/repositories/testing.git/
[master (root-commit) 24eee08] start
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/gitolite.pub

公開鍵はもう必要ないので消しておく。

$ rm gitolite.pub

gituser の HOME 直下に、Gitolite 関連のファイルやディレクトリが作成されているので確認してみる。

$ ls -l -a
合計 44
drwx------  5 gituser gituser 4096  5月 26 10:39 2012 .
drwxr-xr-x. 4 root    root    4096  5月 26 10:17 2012 ..
-rw-------  1 gituser gituser    3  5月 26 10:31 2012 .bash_history
-rw-r--r--  1 gituser gituser   18  5月 11 03:45 2012 .bash_logout
-rw-r--r--  1 gituser gituser  176  5月 11 03:45 2012 .bash_profile
-rw-r--r--  1 gituser gituser  124  5月 11 03:45 2012 .bashrc
drwx------  6 gituser gituser 4096  5月 26 10:34 2012 .gitolite
-rw-r--r--  1 gituser gituser 4217  5月 26 10:33 2012 .gitolite.rc
drwx------  2 gituser gituser 4096  5月 26 10:34 2012 .ssh
-rw-------  1 gituser gituser    0  5月 26 10:34 2012 projects.list
drwx------  4 gituser gituser 4096  5月 26 10:34 2012 repositories

gl-setup で指定した公開鍵ファイルは、自動的に .ssh ディレクトリ内へコピーされている。名前もちゃんと authorized_keys になっている。

Gitolite の設定ファイルは .gitolite.rc となる。あまり変更することはないと思われるが、ファイルの位置だけは覚えておこう。Gitolite を利用してリポジトリを追加した場合は、repositories ディレクトリ内に作成される。デフォルトでは以下の 2 つが用意されているはず。

$ ls -l repositories/
合計 8
drwx------ 8 gituser gituser 4096  5月 26 10:34 2012 gitolite-admin.git
drwx------ 7 gituser gituser 4096  5月 26 10:34 2012 testing.git

Gitolite のリポジトリ設定は gitolite-admin.git に格納される。このツールの特徴でもあるのだがリポジトリやユーザーを設定する場合はリポジトリをローカルに clone して設定ファイルを編集する。変更を反映する場合はそれを Git で push する。リポジトリに対する変更がそのまま Gitolite の操作となるわけだ。実に面白い設計である。

最後に gituser からログアウトしておこう。

$ exit
logout

これで普段 SSH ログインしているユーザーに戻ったはず。

SSH 接続の許可

ローカルから VPS 上の Gitolite へ SSH 接続できるようにするため、設定ファイルを開く。

$ sudo vi /etc/ssh/sshd_config

そして AllowUsers に gituser を追加する。もしこの設定がなければ項目ごと追加しておく。AllowUsers の内容は SSH 接続したいユーザーを半角スペース区切りで列挙する。いつも SSH 接続してログインしているユーザーが XXXX として、gituser を追加した場合は以下のようになる。

# AllowUsers
AllowUsers XXXX gituser

編集が完了したらファイルを保存して、SSH デーモンを再起動する。

$ sudo service sshd restart
sshd を停止中:                                             [  OK  ]
sshd を起動中:                                             [  OK  ]

設定を間違えるとこれまで SSH 接続しているユーザーでログインできなくなるので注意する。念のためもうひとつターミナルを開き、いつものユーザーでログインできることを確認しておいたほうがいい。

もしログインできなくなっていた場合は設定を修正してから SSH デーモンを再起動してログインできることを確認する。

間違えたあとにターミナルを閉じてしまいどうにもならなくなった場合は、さくらのVPS のコントロールパネルにあるリモートコンソールからログインして設定を修正する。ただし、リモートコンソールだと vi で方向キーが効かない ( ダイヤモンドカーソルのみ受け付けるようだ ) ので注意する。

動作チェック

Gitolite のセットアップと SSH 接続の許可が完了したので正常に動作していることを確認するため、はじめから用意されているテスト用リポジトリ testing をローカルマシンへ clone する。

Windows なら msysGit、Mac ならターミナルで適当なフォルダに移動して以下のコマンドを実行する。gitolite.example.com の部分は前述の config ファイルで設定した HOST の名前を指定すること。

$ git clone gitolite.example.com:testing
Cloning into 'testing'...
warning: You appear to have cloned an empty repository.

もし、以下のようなエラーが表示された場合は、config ファイルか、VPS 上の SSH 許可設定が間違っているので、よく見て修正すること。ありがちなのは、config ファイルの USER や ssh_config の AllowUsers 指定ミスである。

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: The remote end hung up unexpectedly

clone できたら、testing フォルダの中に移動して、そこに README.md というテキスト ファイルを作成する、このファイルに適当な内容を記述して保存した後、以下のコマンドで VPS 上のリポジトリへプッシュしてみる。

$ git add .
$ git commit -m 'test commit.'
[master (root-commit) d780560] test commit.
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 221 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitolite.example.com:testing
 * [new branch]      master -> master

成功なら上記のような感じになるはず。実際に push されたことを確認するために、まったく別のフォルダへ移動してから testing リポジトリを clone し直してみよう。

$ git clone gitolite.example.com:testing
Cloning into 'testing'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
$ cd testing
$ ls -l
total 1
-rw-r--r--    1 XXXX  Administ       May  26 11:41 README.md

ばっちり。

ユーザー追加

初期状態の Gitolite には管理者しか存在していないので開発用ユーザーも登録しておく。

前述のSSH 接続用の鍵と設定ファイル作成を参考に新しい鍵と config を追加する。ユーザー名を example とした場合、秘密鍵は gitolite-example、公開鍵は gitolite-example.pub というファイル名にしておく。

.ssh フォルダ内には様々なサービスの鍵ファイルが集約されるので、目的やユーザー名が分かりやすい名前を付けることで混乱を避ける。鍵ファイルを .ssh フォルダに移動した後、config へ以下の内容を追記する。

HOST gitolite.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite

HOST gitolite-example.example.com
    HOSTNAME     example.com
    USER         gituser
    PORT         XXXX
    IDENTITYFILE ~/.ssh/gitolite-example

HOST と IDENTITYFILE 以外は管理者と同じ設定になる。

次に Gitolite の管理用リポジトリをローカルマシン上に clone する。以降、何度も利用するので clone 先は分かりやすい場所にしておくこと。

$ git clone gitolite.example.com:gitolite-admin
Cloning into 'gitolite-admin'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.

clone されたリポジトリ >gitolite-admin のフォルダ内は以下のような構成になる。

フォルダ 内容
conf リポジトリ設定を格納するディレクトリ。
conf/gitolite.conf リポジトリの設定ファイル。内容はプレーン テキスト。
keydir Gitolite を利用するユーザーの公開鍵を格納するディレクトリ。
keydir/gitolite.pub Gitolite の管理者となるユーザーの公開鍵。VPS 上で gl-setup を実行したときに引数へ指定したファイルになる。

ユーザー登録は keydir に公開鍵を追加することでおこなう。

先ほど作成した鍵のうち gitolite-example.pub を keydir にコピーして、ファイル名を example.pub に変更する。この名前が Gitolite 上のユーザー名となる。.ssh フォルダと異なり keydir は Gitolite ユーザーの公開鍵だけ格納されるので gitolite- という接頭語は不要である。

keydir に鍵を用意したら msysGit の GitBash や Mac のターミナルで gitolite-admin/keydir に移動し、commit してから VPS 上に push する。

$ cd gitolite-admin/keydir/
$ git add .
$ git commit -m 'added example user key.'
[master 0201612] added example user key.
 1 file changed, 1 insertion(+)
 create mode 100644 keydir/example.pub
$ git push
... 中略 ...
remote:
remote:                 ***** WARNING *****
remote:         the following users (pubkey files in parens) do not appear in any access rules:
remote: example(example.pub)
To gitolite.example.com:gitolite-admin
   24eee08..0201612  master -> master

成功すると、上記のような感じになる。このユーザーでリポジトリ操作できることを確認するため testing リポジトリを clone してみる。

$ git clone gitolite-example.example.com:testing
Cloning into 'testing'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

ばっちり。

リポジトリ作成

ユーザーが作成できたので次はリポジトリを作成してみる。ローカルに clone した >gitolite-admin の中にある conf/gitolite.conf をテキストエディタで開く。すると以下のような状態になっているはず。

repo    gitolite-admin
        RW+     =   gitolite

repo    testing
        RW+     =   @all

repo で始まる行がリポジトリ設定の開始となり repo の後に続くものがレポジトリ名である。次の行にある RW+ がレポジトリの読み書き属性で R が読み取り、W は書き込み、+ を付けると Git の reset コマンドを許可する設定となる。属性とイコールで結ばれた先が属性に関連づけるユーザー名となる。

上記の例で説明すると gitolite-admin は管理者 gitolite によって RW+ が可能、testing は全てのユーザーで RW+ が可能となる。

Gitolite によるリポジトリの増減はこのファイルの設定と push によっておこなう。今回は new-repo という名前のリポジトリを追加し全ユーザーに R、example というユーザーだけに RW を許可してみる。gitolite.conf へ以下のように追記してファイルを保存する。

repo    gitolite-admin
        RW+     =   gitolite

repo    testing
        RW+     =   @all

repo    new-repo
        R      =   @all
        RW     =   example

ファイルを保存したら msysGit の GitBash や Mac のターミナルで gitolite-admin/conf に移動し、commit してから VPS 上に push する。

$ cd gitolite-admin/conf/
$ git add .
$ git commit -m 'added new-repo repository.'
[master 10cbb2e] added new-repo repository.
 1 file changed, 4 insertions(+)
$ git push
... 中略 ...
remote: creating new-repo...
remote: Initialized empty Git repository in /home/gituser/repositories/new-repo.
... 後略

成功すると上記のようになる。push 後のメッセージを読むと new-repo という空のリポジトリが作成されたとあるので、さっそく適当な場所に clone。

$ git clone gitolite-example.example.com:new-repo
Cloning into 'new-repo'...
warning: You appear to have cloned an empty repository.

ばっちり。

レポジトリを削除する場合は gitolite.conf から設定を削除して commit & push する。例えば先ほどの new-repo を削除したあと再び clone を試みると…

$ git clone gitolite-example.example.com:new-repo
Cloning into 'new-repo'...
R access for new-repo DENIED to example
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly

といったエラーとなり clone に失敗する。ただし VPS 上に作成されたリポジトリの実体は残っているので不要ならサーバーにログインして完全に削除しておく。

$ sudo su - gituser
$ cd repositories
$ rm -rf new-repo.git
$ exit

Gitolite のリポジトリを Redmine から参照する

Gitolite のリポジトリと Redmine プロジェクトの連携を試してみる。

Gitolite リポジトリに対するにミラー ( bare ) リポジトリを作成し、Redmine からはそれを参照する。今回は Gitolite にデフォルトで用意されている testing リポジトリで試す。

VPS にログインした後、先に用意しておいた Git のリポジトリルートに移動し、ミラーリングリポジトリを生成する。用意できたらリポジトリのディレクトリ所有者を Redmine のユーザー:グループ ( このシリーズの手順 で環境構築しているなら、いつも SSH 接続でログインしているユーザー ) に変更して Redmine から参照できるようにする。

$ cd /var/lib/git
$ sudo git clone --mirror /home/gituser/repositories/testing.git
$ sudo chown -R XXXX:XXXX testing.git

ここからは Redmine 上の作業となる。まず Redmine にログインし、Git リポジトリを関連づけるプロジェクトを開く。そしてメニューから「設定」→「リポジトリ」を表示。

![Redmine の設定画面](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-01.png "Redmine の設定画面")

新しいリポジトリボタンを押してリポジトリ設定を表示する。そして以下のように指定したら作成ボタンを押す。

![新しいリポジトリ](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-02.png "新しいリポジトリ")

これにて関連づけ完了。プロジェクトのメニューからリポジトリを表示してみる。

![Gitolite からのミラーリポジトリ表示](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-03.png "Gitolite からのミラーリポジトリ表示")

ばっちり。もし 404 エラーが出る場合はリポジトリのパスや参照するディレクトリのパーミッション、所有者の設定を見直してみること。

GitHub のリポジトリを Redmine から参照する

GitHub 上のリポジトリを Redmine から参照する場合も Gitolite と同様にミラーリポジトリを作成すればよい。まず GitHub 上のリポジトリページを開きページ上部の Git Read-Only ボタンを押して読み取り専用 URL を得る。

![GitHub](http://akabeko.me/blog/wp-content/uploads/2012/06/revps-10-04.png "GitHub")

次に VPS へログインし GitHub 上から得た URL を指定してミラーリポジトリを作成。そして所有者を Redmine 用に変更する。

$ cd /var/lib/git
$ sudo git clone --mirror git://github.com/akabekobeko/WP-Nicodo.git
$ sudo chown -R XXXX:XXXX WP-Nicodo.git

Gitolite の時と同様に Redmine 上でリポジトリの作成画面を表示、以下のように設定して作成ボタンを押す。

新しいリポジトリ その 2

リポジトリ画面を開き確認。

GitHub からのミラーリポジトリ表示

Gitolite、GitHub ともに参照だけなら今回の設定でよいが、このままだとリポジトリの push が反映されない。

同期する場合はミラーリポジトリに対して git fetch を実行すればよいのだが手動でおこなうのは面倒である。そのため cron などで定期実行するか push をハンドリングしてオンデマンドに実行されるようにしたい。その方法も書きたかったのだけど、記事があまりにも長くなりすぎたのと GitHub 側の方法を検討中なので次に持ちこす。

というわけで、今回はここまで。次回は Gitolite や GitHub の push をハンドリングして、ミラーリポジトリへ自動反映する方法を検討してみる予定。

msysGit を入れてみる

2011年4月10日 0 ソフト紹介 ,

マシンをセットアップする時に msysGit のインストールで迷わぬよう、設定とそれを選んだ利用について記録しておく。

まず msysGit の入手だが、以下のサイトに公開されているものをダウンロードする。

現時点 ( 2011/4/10 ) の最新版は Git-1.7.4-preview20110204.exe である。ダウンロードした後にこれを起動するとセットアップ ウィザードが開始される。Next ボタンを押して次へ。

ようこそ画面

ライセンス確認。一読してから Next ボタンを押して次へ。

EULA

インストール先の選択。msysGit は 32bit プログラムなので、OS が 64bit Windows なら Program Files (x86) が自動的に選ばれる。特に変更しなくてもよい。Next ボタンを押して次へ。

インストール先の選択

いろいろな設定を選ぶ。

  • Additional icons はショートカットの作成先。デスクトップとクイック起動を選べるが、スタート メニューからも選べるので、どちらも不要。チェックを外す
  • Windows Explorer integration はシェル拡張。エクスプローラ上のコンテキスト メニューに Git 関連を追加できる。Git の操作は Git Bash のコマンド ( cd なども用意されている ) で十分。あとエクスプローラをいじられるのって、何となく嫌だ。というわけでチェックを外す
  • Associate .git* configuration …、これはファイルの関連づけ。他に Git 関連の設定を使うアプリはないだろうから、これはチェックしたままにする
  • Use TrueType font …、コンソールで TrueType フォントを利用する設定とのことだが、メリットは不明。これをチェックすると Windows のコマンド プロンプトで日本語が化けるので不要。チェックを外す

設定したら Next ボタンを押して次へ。

関連づけなど

スタート メニュー項目の設定。標準でよい。Next ボタンを押して次へ。

スタート メニュー項目

パス。いわゆる環境変数の設定。

Windows のコマンド プロンプトを拡張したり UNIX 系ツールをインストールできるが Git を利用する分には Git Bash があれば十分だしそれ以外の環境をいじられたくない。というわけで最上段の Use Git Bash only を選ぶ。

Next ボタンを押して次へ。

システムのパス設定

改行コードの設定。

最上段の Checkout Windows-style, commit Unix-style line ending が推奨とのこと。これを選ぶとテキストの改行コードをチェックアウト時に CRLF、コミット時は LF に変換してくれる。個人的には as-is ( 変換なし ) の方がよさそうに思えるのだけど推奨に従う。

Next ボタンを押して次へ。

改行コードの設定

インストール開始。それほど時間はかからない。

インストール中...
インストール完了。リリース ノートを読みたければ View ReleaseNotes.rtf をチェックしておく。Finish ボタンを押して終了。

インストール完了

Git を使う方法としては他に Cygwin があるのだけど、こちらは Windows 自体をいろいろと変更することで UNIX ライクな環境を提供する。Git もその中のツールとして利用することになる。

一方 msysGit の変更はセットアップ時の設定により限定的にできるので、単に Git を利用したいだけならばこちらの方がよいだろう。

Git Bash は cd や ls、cp、mv などの基本的なシェル コマンドを用意しておりファイル操作も可能である。さりげなく vi ( VIM ) までありテキスト編集もいけるので Cygwin ほどの拡張性はないが、ちょっとした UNIX ライクな環境としても便利だと思う。

あと最近、Titanium Studio 1.0 Preview 版を入れたのだが、この時の初回起動で表示されてた Git 関連のエラーは先に msysGit を入れておけば発生しない。職場のマシンで確認した。

ちなみに msysGit を後から入れても Titanium Studio はちゃんと検出してくれる。msysGit があると IDE 上からサンプル プロジェクト ( Kitchen Sink など ) を取得したり、自作プロジェクトのバージョン管理にも利用できるので Titanium Studio ユーザーなら入れて損はないだろう。