2014.05.17

MAMP+WordPressのローカル開発環境にgitもプラス

必然というかWordpressも2台のMacで開発したくなってきたので、git管理下に置いてみることにしました。

と、言ってもMAMPで構築したローカルのテスト用Wordpressについてです。
公開サーバーがsshに対応してないのでリモートリポジトリもローカルLAN内に置きます。
テスト環境で仕上げた完全版をftpsで上げるという赤貧でめんどくさい清貧で健気な話になりますw。

めんどくさいというダメな理由で工夫をするのだ

git_wp_k
既にメイン機には、MAMPを使用したWordpress開発環境があります。サブ機にはありません。
Wordpressというのは普通のサイトと違ってデータベースがないと動かない訳ですな…
しかしサブ機にまたMAMPを入れてWordpress環境を構築したりするともう一つ環境が増えちゃう訳で…めんどう。
どうにかメイン機のデータを共有したい。そしてサブ機のブラウザからもプレビューできるようにしたい。

メイン機にあるWordpress用ディレクトリはDocumentRootにしてヴァーチャルホストの設定をしてあります。
サブ機で作業をした時、このメイン機のDocumentRootの内容を変更できればいいよねということで!
この元々使っているDocumentRootディレクトリをgitのposts-updateフックを介してサブ機から変更できるようにしたいと思います。

もちろん、本番用と開発用のブランチを使い分けねば危険。
リモート、ローカル共に常設のブランチを2つ用意しました。

  • ftpsの為の本番用ブランチ master
  • 作業&プレビュー用ブランチ develop

開発はdevelopで行い、決定版をmasterにローカルmergeするルールで運用します。

post-updateでブランチを分岐して、それぞれのブランチごとにremoteにpushしたら、ローカルwordpressディレクトリ(DocumentRoot)に自動でpullしてくるようにする。

  • remoteのmasterにpush、ローカルのmasterでpull
  • remoteのdevelopにpush、ローカルのdevelopでpull

管理する人間は一人なので同時にdevelopブランチを操作していることはないという前提です。
なんか落とし穴があるような気もしないでもないですが、とりあえずやってみることに。

Aptanaのせいで!めんどくさいけどWP専用.gitignoreを作る

WordPressやプラグインの追加・アップデートはブラウザからするので、gitで管理するのはthemes/自分のテーマディレクトリ以下になります。
もともとそこしか触った事無いもんね(‘A`)

なのでおもむろに自分のテーマディレクトリwasino-themeをgit initしました。
しかし、愛用のAptanaはプロジェクト/サブディレクトリのgitリポジトリをいっさい受け付けません。がーん。
Aptanaのターミナルは使えるけど毎度addとかcommitとかpushとかcheckoutとかmergeとか打ち込むのもめんどくさい。
どうやらAptanaのGUIでgitを使うにはプロジェクト単位でやるしか無いようです。

プロジェクト=Wordpressディレクトリ直下にローカルリポジトリを作成。
直接編集しないファイルは.gitignoreに追加して無視することで、オリジナルのテーマだけを管理することにしました。

さて、既存のWordpressディレクトリwasino-wpでリポジトリの初期化initしたあと、.gitignoreを書きました。

.gitignoreの中身はこんな感じ。

wp-*.php’で接頭詞にwp-が付いたphpは全部無視。
先に色んな階層にあるindex.phpを全て無視しているので先頭の’!’でテーマの中のだけ除外。
とにかく自分がエディタなどで編集しないものは全て無視してあります。
gitignoreの表記が正しかったかどうか一応、statusで確認しておきますた。

.gitignoreは別の環境でも使い回しますのでリモートに上げます。この段階ではまだコミットだけ。

リモートリポジトリはまだ無いけど、ローカルのコンフィグに設定しておきます。

次にリモートリポジトリを作ります。あ、すべてローカル環境での出来事です。

set upstreamを忘れずに

WPディレクトリに戻ってpushします。
警告がうざいのでmasterを -uオプションを付けてトラックしておきました。

デフォルトを愛しているので、pushの挙動をsimpleにしてあります。

simpleはカレントブランチをpush。同名のブランチがリモートにない時はpushしない。
詳しくはこちら。

参考サイト:
gitのpush.defaultに関するノウハウ
git の push.default 設定を理解する

このsimpleを使う為に設定したオプション-u(–set-upstream)が、めんどくさいからと始めた試みに知らず知らずに効いていた。便利さに感動。
というか、これをしていないと…

post-updateのpull先でbranchを分けるときにやっておくこと

post-updateをつかってbranchごとにpullする時、
pullする側でupstreamをセットしてないと、ぜーんぶmasterにマージされちゃう(`ェ´)ピャー

これが出来ないと、今回の目論みは全部失敗なのでぃす…

upstreamをセットするには、

push時に-uオプション付けてたら既にセットされてます。効いてる効いてる。

今回のテストで「ディレクトリごとにpullするpost-updata」テスト用一式を使い回して、全部masterにマージされて悩んだんですよね。
origin developって引数つけたからorigin/developにはfetchして来てる。でもdevelopにmergeするなんて明示してないから(´・ω・`)?
そういえばテスト用のはpost-updateでpullしてくるだけのディレクトリだったから、pushもしてないし、upstreamもセットってしたことないよね…
でもでも、config -lで見てもbranch -vvで見ても、merge先はセットされている。うっ。

push、pull共に

でset状況を確認できるらしい。
こちらを読むとpushはセットされてるけど、pullがセットされていなかったらしいことが分かりました。

参考サイト:
Gitでブランチをリモートに送る時の注意点 – rcmdnk’s blog

ん?remote show するとmergeの所にdevelopは無い…これかい。なんでローカルには設定されていたのか分からないけど。

よし!これでpost-updateでブランチを分岐させる&upstreamのセットで、無事にdevelopにpushしたらdevelopでpullが出来るようになりました。
サブ機側は、普通にremoteからcloneしてきます。upstream関連、デフォルトの挙動とsetを同じく設定する。

追記:と思ったら、pullする側のDocumentRootでカレントブランチにしかpullされません。(´・ω・`)
サブマシーンのdevelopからpushした時に、DocumentRoot側でmasterに居ると、fetchはしてるんだけどmergeされてない。出来た!と思ったんだけど勘違いだったのかなぁ…。
簡単にpost-updateでpullの前にcheckoutを差し挟む事にしました。

運用してみて

サブ機からは画面共有などでDocumentRootのbranchを切り替える術がないと、多少めんどくさい運用になりますな。
あと、サブ機からプレビューしたいばっかりに、こまごまとしたコミットが増えます。メリットもあるかもしれないし、rebase -i とかなんとか覚えなきゃならないかもしれない。(pushした後でのrebaseになるので、破棄前提のブランチを作り作業しなくてはならない。面倒。この実験した後、カレントブランチでしかpullできなくなったような気がするんだす…)

メイン機からpushすると、それをまたメイン機に自動でpullしてくることに疑問を感じるかもしれない。
特に警告もでないし、気にしない方向で…

おまけ '.' てなにさ!

remote: fatal: Not a git repository: ‘.’
いつも出てるむかつく致命的エラー
私の作った環境では、post-updateで –git_dir=.git オプションを付けているにも関わらず出ます。
普通にpullが成功しているだけにちょーイライラします。
GIT_DIR=”.git”もだめ。

でこの '.' ぽかーんとした顔見たいなのは居なくなりました。よかった。

コメントをどうぞ



PageTop