Gitのリポジトリを後から共有設定する

さてさて、どうにかこうにかイカした開発環境を作れてホッとしていたのだが、実際に運用してみたところ、上手く動かないケースが出てきた。

hogeユーザが

git push origin master

とやって共有リポジトリにプッシュした後、tadasukeユーザが

git pull orgin master

で更新を落としてくることはできるのだけど、さらに修正して

git push origin master

とやると、パーミッションエラー的なメッセージが出てプッシュできない。

共有リポジトリの

/var/git_repos/game.git

のパーミッションは775に設定していて、hogeとtadasukeは同じグループなのに…

どうもpushしたタイミングでファイルのパーミッションが書き換わってしまうらしい。

pushする度にファイルのパーミッションを変更するのは面倒すぎるので色々調べてみたところ、リポジトリを作る際に

--shared=true

オプションを設定するとリポジトリが共有設定になって、同じグループのユーザであればpushしまくっても問題なくなるらしい。

ただ、すでにリポジトリは作成済みなわけで、新たに作り直すのはできることならご遠慮願いたい。

で、さらに調べたところ、

/var/git_repos/game.git/config

の[core]のところに

sharedrepository = 1

と書いてやれば、共有リポジトリになることが判明。

もしかすると

sharedrepository = true

のほうが、正しい書き方かもしれないけど・・・

というわけで、今度こそイカした開発環境ができましたー。

Gitの共有リポジトリを使った開発環境の作成

先週をほぼ丸々使って、かなりイカした開発環境を作ることができた。

ざっと要約すると、

• 開発環境から本番へのアップロードには現状のSVNを使ったまま、
• 開発環境内のバージョン管理のみGitを使い、
• 複数の開発者が同時に開発でき、
• 一台の開発サーバで別々のテスト環境をもてる

という、ちょっとこれは凄いんじゃないかと個人的には自負している。

前回の記事で、開発者ごとに同一の開発サーバで別々のドキュメントルートを使えるようにするやり方を書いたので、今回はその続き。

元々のソースファイルなどは

/web/game

に存在しているので、まずはその内容をGitの共有リポジトリに登録する必要がある。

どちらにしてもリポジトリを作らないことには話にならないので、
/varにgit_reposというディレクトリを作り、そこで

git --bare game.git

とコマンドを叩いてやる。

次にこのリポジトリのクローンを作る。

git clone /var/git_repos/game.git /web/new_game

「空のリポジトリだよー」とワーニングのメッセージが出るのだけど、華麗にスルー。

次に/web/game/の中身を/web/new_game/にごそっとコピー。

きちんとGitで管理できているのかどうか、new_gameに移動して

git status

コマンドを打ってみると、ごっそりとGitに未登録のファイルが出てきた。

ここで

git add --all

としてやればまずはGitのステージに登録できるのだけど、statusの一覧を見てみると、大量の.svnファイルが含まれている。

開発環境から本番にアップするのにはSVNを使うので.svnファイル自体は必要なのだけど、Gitには登録したくない。

というわけで、.gitignoreファイルを作成し、.svnを無視リストに加える。

その後、おもむろに

git add --all
git commit -m 'add new file'

としてGitに登録。

そして、

git push origin master

として、共有リポジトリに追加する。

次に/web/game_tadasukeとうディレクトリを作成する。

そんでもって

git clone /var/git_repos/game.git /web/game_tadasuke

として、共有リポジトリからソースファイルを落としてくる。

後は前回の記事のようにユーザによってドキュメントルートを
/web/game
or
/web/game_tadasuke
に切り替えてやれば、ユーザごとに別々の開発環境ができてテストまでできちゃうようになる。

うーん、素晴らしい。

まだ運用を開始して日が経っていないので、後は実際に使いながら細かく修正していく感じですな。

FiddlerでHTTPヘッダーの改ざん

現在の開発現場で担当しているのはとあるソーシャルゲーム。

サーバ側プログラマーは自分一人だったので、開発サーバのディレクトリをローカルのMacでマウントしてそこをEclipseのWorkspaceにしちゃうという、かなりアクロバティックなやり方をしていた。

これだと、
コーディング　→　サーバにアップ
という作業が必要なく、コーディングしたものがすぐに反映されるのでかなり重宝していた。

ただ、もう一人サーバ側プログラマーが加わったこともあり、何より「さすがにちょっと危険かも」という気がしてきたので、やり方を見直すことにした。

では、実際にどのようにすればいいのか。

必要要件としては以下のとおり。

• 開発者ごとに別々に作業ディレクトリがある
• 動作確認はローカルではなくサーバで行う
• フロント側のFlashやJSは共通のものを使う
• 全環境でソースは設定ファイルに至るまで共通

まずは簡単なところから手を付ける。

開発サーバに
・共通作業ディレクトリ
・プログラマーA作業ディレクトリ
・プログラマーB作業ディレクトリ
を作成。

Apahceのバーチャルホストの設定で
・dev.example.com　→　共通作業ディレクトリ
・hoge.dev.example.com　→　プログラマA作業ディレクトリ
・fuga.dev.example.com　→　プログラマB作業ディレクトリ
とドキュメントルートを設定。

ここまではいいのだけど、問題はここから。

Flashから呼ばれるAPIのホスト名はdev.example.comとなっていて、共通のFlashを使うので、どうにかして
・プログラマA　dev.example.com　→　hoge.dev.example.com
・プログラマB　dev.example.com　→　fuga.dev.example.com
としてやる必要がある。

そこで登場するのがFiddlerというweb debugerツール。

今までも通信ログの確認などでは使っていたのだけど、調べてみるとかなりディープなことができる模様。

【Rules】→【Customize Rules】をクリック。

そうするとテキストエディタが起動するので、OnBeforeRequestというファンクション内に、

if ( oSession.HostnameIs( "dev.example.com" ) ) {
    oSession.hostname = "hoge.dev.example.com";
}

と書いてやる。

ようするに、飛び先のホスト名がdev.example.comの時はホストをhoge.dev.example.comに置き換えちゃえと指定してやるわけだ。

で、上書き保存してdev.example.comにアクセスすると、しっかりとhoge.dev.example.comに飛ぼうとしてくれた。

参考URL：http://www.fiddler2.com/fiddler/dev/scriptsamples.asp

後はhostsの設定をしてhoge.dev.example.comの飛び先のグローバルIPをdev.example.comのグローバルIPにしてやればいいんだけど、hostsに書くんじゃなくて、さっきのプログラムに書くやり方でできないかなーと探してみたところ、ばっちり見つかった。

if文内に

oSession["x-overrideHost"] = "飛び先のグローバルIP";

と書いてやると、意図したとおり動いてくれた。

いやー、Fiddlerって凄いっす。

調べれば調べるほど奥が深いし、色々と悪いこともできちゃいそうな気がする・・・

後はそれぞれの作業ディレクトリをGitで管理してやれば素敵なことになるだろうから、引き続きGitの勉強を頑張るのです。

Gitのお勉強中

今までは現場でSubversionを使っていたのだけど、正直言うとあまりきちんと理解できていない。

このままではイカンと思って勉強しようかと思ったのだが、ふと
「今からSubversionの勉強するより、Gitの勉強したほうが今風じゃない？　ナウじゃない？」
と思い立ち、Gitの勉強を始めてみた。

いずれはGitHubをバリバリ使いこなせるようになりたいっす。

とりあえず今のところGitの機能で便利だなーと思ったのは、ステージという概念。

SVNだと、あるファイルを編集しリポジトリにコミットする時は
svn commit -m 'add hoge' hoge.txt
とするのだけど、
Gitの場合は

git add hoge.txt
git commit

みたいなやり方ができる。

なんで、すでにバージョン管理しているファイルをコミットするのにaddが出てくるのかというと、hoge.txtをステージにアップするためだ。

ステージというのは、作業ツリーとリポジトリの中間みたいなところで、コミットする前にそこに一度アップすることができる。
※直接コミットももちろんできる。

ステージが便利だなーと思った理由は次の2点。
1.複数のファイルをまとめてコミットしやすい
2.ちょっとしたブランチのように使える

まず、1。
SVNで複数のファイルをファイル名を指定してコミットしたい場合、

svn commit -m 'ver1.2 release' hoge_1.txt hoge_2.txt hoge_3.txt ・・・

などと、ダラダラとファイル名を追記していく必要がある。
このやり方だと、どうしてもミスが多くなる。
ファイルごとにコミットすると、無駄にリビジョン番号が増えていくし、ログも追いにくい。
その点、Gitのステージを使えば、コミットしたいファイルをまずはステージにaddにして、あとで一度だけ

git commit -m 'ver1.2 release'

とすればバッチリOK！！
もちろん、間違えてステージにaddしてしまった場合は、簡単に元に戻せる。

次に、2。
hoge.txtを編集し、

svn add hoge.txt

をやってステージにアップする。
その後、もう一度hoge.txtを編集して保存すると、
hoge.txtのバージョンとしては、
・リポジトリにあるhoge.txt
・ステージにあるhoge.txt
・作業ツリーにあるhoge.txt
と3種類存在させることができる。
ステージのバージョンと作業ツリーのバージョンが違う状態というのはあまり健全ではないだろうから、別々に管理したいときはブランチを切るのが一番だろうけど、リリース直前にちょっとソースを弄りたくなった時とかにはかなり重宝しそう。


まだ勉強を初めて間もないので分からないことだらけだけど、今のところはなかなか使い勝手もよくて楽しそう。

引き続きお勉強をして、またブログに書いていきますねー。