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”もだめ。

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

2014.05.03

pen&touchで軽装備だけど重装備

モバイルもペンタブ欲しいよね。
という、新しいMacを買ったら連鎖的にいろんな物を買ってまうシリーズーぅ!な、訳で。父さん。
買いました。intuos。
intuos_c_pack
と言っても、以前はBamboo Funとしてラインナップされていた廉価機種なんです。現在はintuos pen&touchとかになってます。
そのコミックソフトバンドル版のintuos comic sというのを買ってみましたお。

機種からセレクト

一番廉価な機種に intuos penがありますが、今回これ↓は見送りました。

pen&touchとの違いはtouch機能がない、バンドルソフトが水彩LITE、ふぉと7(Windows専用)だけ。
それとペンのお尻に消しゴムがありません。
消しゴム機能そのものはソフト側の制御なので、無くても特に困りませんけど…
ペンのお尻の消しゴム機能割当に馴れきっているため、無いのは地味に不便そうだったので今回はpen&touchを選択しました。

サイズ選択とproとの比較で泥沼に迷う

本体はintuos Proと迷ったんだけど、wacomサイトがあまりにも見難い為比較検討するのがいやになり、いいじゃんpen&touchで一万円以内で買えるし!買えるし!と勢いでポチることになりました。

嘘です。ちょー比較しました。
前提に持ち運びがあったので、絶対Sサイズは譲れない線。
Mサイズは、MBP13incの一回り小さいくらいで、ほぼ同じ大きさ…デカっ。
頑張って持ち運んだとしても、出先でMBPとペンタブを広げられるスペースが確保できるか否か。コーヒーチェーン店の一人掛けテーブルではMBP置いて精一杯だろうし、そういった所では長居する作業もしないだろうけど…やっぱ大きすぎます。
やっぱりSサイズに決定。

そうするとproのSサイズという選択も生まれるわけで。
proイイよね!というか今回pen&touchを選ぶにあたってbambooとか使った事無かったので多少の不安が。
しかし、どうせproを買うならメイン機に欲しい。…メイン機で使うなら、今intuos3(Mサイズ相当)だしMサイズが欲しい…
当初の機動設定を忘れて、泥沼に陥りました。
そこで物欲を抑え、冷静に戻る。
Mac Bookではなんのソフトを使うんだっけか?
Illustratorを使いたくて、マウスやだなーと思ったのでした。
おお、やっぱりpen&touchでいいんです。危うく物欲に負けるところだった。

ペイント系のソフトで大きく腕を動かして描きたいという理由がなければ、モバイル用途やスペース苦心してまで大きいタブレットは必要ないと思いますお。
Illustratorのようなドロー系ソフトではタブレットの大小は問題にならないです。個人的には大きい方が不便な気がしないでもないです。特にマウスでの操作に慣れていると、操作ポイントまで遠いわーというという気がするかもしれません。慣れですが。

バンドルソフトからセレクト

通常のpen&touchには
☆Photoshop Elements11(ダウンロード版)
☆ArtRage 3.5 Studio(ダウンロード版)
が付いてきます。

えっ!いいなぁ〜!!
お小遣いが少ない学生さんはこのソフトで十分勉強になるよ。
わしの若い時にこんなソフトがバンドルされたものがあればなぁ。必死こいてPhotoshopと小さなペンタブ買ったよね。

Photoshop Elementsはphotoshopのさわりの勉強に凄くいいと思う。
実際、webだけしか扱わない会社ではElementsで素材バリバリ作ってるとこもあるし。
ArtRageは触った事ないけど、代表格でもあるPainterも含めペイント系のソフトって操作を熟知するってのは実はどうでもよくて、純粋に描くための道具だと思う。
ArtRageをググってみたところ描く事を学ぶには十分なソフトではないかと。

しかしわしにはすでにPhotoshopもあるし、painterもあるし…
線の補正機能があるソフトって使ったことないし試してみますかという事で!
未知のお絵描きソフトの入ったcomicエディションを選んでみましま。

pen&touch comicには
☆CLIP STUDIO PAINT PRO(ダウンロード版)(二年期限限定版)
というのと、あとは水彩とかMacでは使えないソフトが付いてきます。ブー!
Macで使えるのはCLIP SUTUDIO PAINT PROだけなので、外は割愛。

パッケージ内容とドライバインストール

intuos_c_in
画像に写っていない物はタブレットの裏蓋に収納されている替芯と替えの布製ペンホルダーとペンの黒い輪っかです。
左下はおしゃれな手編みの靴下を履いた私の足です。ごめん。
入ってるDVDはドライバインストール用です。バンドルソフトはダウンロードになります。
って、ちょっと通信速度が出なかったのでDVD入れてみてガッカリ。
ドライバ用も結局はダウンロードでした。
袋から出したり面倒臭いので、さくっとダウンロードした方が早いです。
Intuos (CTL-480、CTH-480、680)ってのです。
ダウンロードの際、対話モードのファイアウォールで見事にこけました。お気をつけください。

使用感とジェスチャー

セットするとこんな感じ。sサイズでも幅60cmのテーブルではぴっちりです。よし、想定的中。
intuos_pt_set
ついでに↑モニターに映っているのが、バンドルソフトCLIP STUDIO PAINT PROでの初描きだす。なかなかいい感じに線を補正してくれます。しかし、筆圧コントロールに訓練が必要な模様。

ペン先は芯が3よりも細いです。描いた感触はザラザラ感のあるタブレットのシート面でも滑らず引っかからずほど良いのですが、ペンの反対側消しゴム部分の感触が気になります。
一方向に動かす分にはいいのだけど、ゴシゴシという感じで使うと二度目のゴシで折り返す時に異様に引っかかりを感じ、ちょっと黒板キーッちっくで嫌です。

ジェスチャーついては、intuosのtouchを使うにあたって利き手側で操作ができるのはいいです。
MBPではトラックパッドを体の真ん中で操作しなくてはならず私としては少し使いにくい部分がありましたし。
ジェスチャーはMBPのトラックパッドに3本指ドラッグを割り当てた時と操作が同じです。
しかし3本指スワイプに馴れてしまっているので地味に不便w、操作を全く同じにするのであればMac側のトラックパッドの設定を変えて馴れるしかなさそうです。
も一つ不便なのがMission Controlをジェスチャーに割当られないことです。
仕方ないので、intuosのファンクションキーに割り当てました。
環境設定からタブレット→ファンクションキーでキーストローク 特殊キープルダウンの下から2番目でmission controlが選択できます。

気軽に始める、手軽に使うには良いペンタブ

入門機として、またはセカンドとして、選択するには満足できるペンタブレットです。
ただ当然ですが、intuos4 5からの乗り換えでは不満がでると思いますです。3からでもどうかな。

参考になるかどうかわからないけど、私はこのpen&touchと同じ筆圧レベルのintuos3 PTZ-630をメインで使ってます。
10年ほど前に発売されたペンタブですが、現在のproと同じ位置付けのモデルです。
スペックは
【PTZ-630】
筆圧レベル 1024
傾き検出 ±60レベル
読取分解能 最高0.005mm
読取速度 最高200ポイント/秒
読取精度 ±0.25mm

【pen&touch】
筆圧レベル 1024
傾き検出 なし
読取分解能 0.01mm
読取速度 最高133ポイント/秒
読取精度 ±0.5mm

と、pen&touchは筆圧レベル以外は古いproユースと比べてもスペック的に劣っておるです。
簡単に説明すると読取分解能はセンサーの間隔狭いほど精密、読取精度はペン先位置の誤差、読取速度は一秒間になんぼ読み取るか。

初めてのペンタブにproを購入するのは、もちろんありです。
一度購入したら何年も使えますし。私のPTZ-630は3台目ですが8年使ってます。
何年も使うつもりで購入する分には十分元はとれますw。
自分がどういったスタイルで描くのか、アナログで描くとしたら何の画材を使うのか。その辺に機種選定の目安があると思うです。

でも購入にあたってproは気軽じゃないんですよね。道具に振り回されるというか。
お小遣いを貯める時間を惜しんでpen&touchで描き始めちゃうという選択もおおいにアリだし、いきなり不満が出るペンタブでは無いと思う。
もし私の初めてのペンタブがpen&touchで、パソコンで絵を描き始めたのだとしたら十分に使えて勉強が出来るという感想を持ちましたの。

とか偉そうなことを言っておいて、MBPにもペイント系入れたくなってくる位にいい感じです。
モバイルのセカンドで使うにはもってこいですよ(`・ω・´)。

新しいモデルがでましたね!

あと、これ↓も欲しくなりますが…どうしようかなぁ。コード邪魔なんだよね。

そしてバッテリーということはですよ。MBPのバッテリーも喰わないわけで。
ポチるの数秒前ですわ…

2014.04.19

git-ftp 鵜呑みにできない備忘録

先生、鯖がsshに対応してません! gitでサイト更新ができません!

お得なレンタルサーバーではssh使えないこと多いですよね。
gitのpost-updateを使ってサイトの更新をデプロイできたら、いちいち更新したファイルを覚えてなくてもいいし…あ、css上げるの忘れた!とかもなくなりますしいいですよね。いーなーいーなー。
しかし、鯖をクラスチェンジする金はない。

でも、知っていたんです。
なんか調べてる時に見つけたんですよ。
git-ftpとかいうアイテムを。https://github.com/git-ftp/git-ftp

リモートリポジトリがレンタルサーバーに置けないとしても、更新箇所だけでも手動でアップするよりかは格段に便利な予感。
Aptanaのftpもちょー便利なんですよ!FTPSもSFTPも使えますし、いちいち更新ファイルを覚えていなくても「同期」で一括アップできますし、同期でもファイルの一覧から更新するかしないかも選べます。ちょとした手直しの更新なんてエクスプローラから右クリ一発です。
そこで、どっちがいいか使ってみようと思ってやってみました。
ちょっと色んな事が難しかったんで備忘録つけときます。

この記事のいい加減さ

たぶんちゃんと説明できてません。当記事は参考になりません。ペコ
git-ftpご利用の際はgit-ftp公式の説明をよくお読みになられますよう。
https://github.com/git-ftp/git-ftp
または、こちら。すごく参考になりました。

参考サイト:
Qiita git-ftp インストールと設定(Windows)
インストール

公式のインストールの説明書
Macです。
gitとcurlが必要ですがcurlコマンドは標準で搭載されているらしい。というか、要ると意識しないでやっちゃってました。
SnowLeopardではMacPorts使ってたのでopt/local/binに居るんですよね。
何にも小細工してないMountainLionではusr/binに居ましたがpathが通ってない模様。
この辺よく分からんちんなので、curlはMacPortとかHomebrewとかで落としてきた方がいいのかなぁと。
Portsで落としてきた方には、opt/local/shareにcurl-ca-bundle.crtも入ってましたし…難しすぎ。

ターミナルを起動。ホームフォルダに居ると思うので、そのままgithub.comにある公式からクローンしてくる。

#の所は入れなくていいです。
クローンしてきたらgit-ftpに移動。最新のタグにチェックアウトのちsudoでインストール。
sudoって緊張します。求められるPasswordはrootのじゃなく自分のです。表示されないので正確にタッチしてリターン。

私は最初に古い方の公式からクローンしてきたんで、新しい公式からはアップデートをしました。1.0.0-rc.1が最新だったけど、-rc.1ってなにさ?と思って0.9.0のタグからしましま。(アップデートもありUpdating using git参照
homebrewからもインストールできるようなんで、homebrew入れてたら楽そうでいいです。

git-ftpの設定とイニシャライズ

恐ろしいのでレンタルサーバーにtest用サブドメインを立ち上げました。

ローカルで、テスト用にあらかじめ作って置いたディレクトリ(index.html入り)に移動してgit configに設定をする。

初めてUPする時はイニシャライズのコマンドを使います。

これでftpで繋がりアップロードが始まります。

やっぱりftpsで繋げたいわーという所でコケる

やっぱFTPはこわいわーという事でFTPSで繋がるようやってみたところ大はまりんぐ。

今までもaptanaやあひるで設定していたFTPSサーバーのアドレスを入れたのに

initすると、そんなホストねーし!と怒りのこもったエラー(妄想)が返ってくる。ログを見るとめちょめちょなアドレスが生成されてるわけで。

Aptanaのftpの設定を覗き見ると、SSL MethodのプルダウンでExplicit-AUTH TSL/SSLを選択してある。そういえば、そんな記憶もなきにしもあらずです。
公式のman pageを見るとURLの項目に

えっ!
どうやらcurl(なのか?)はプロトコルのとこ見て動くらしく、ftpsとftpesとで区別しているらしい。(そんならftps://はimplicitなんだろうか?)
試しに

としてみる。ポートはexplicitも同じ21を使う。

そしておもむろにイニシャライズ!init!
あっさりアップが始まりました。(∩・ω・)∩

ここまでの道のり実は相当長かったです…。
プロトコルの表記の仕方だのとは夢にも思わず、証明書のせいかと見当違いを疑ってみたり、知識がないので勉強になりました(´・ω・`)。
しかしAUTHコマンドのトラストストア?(勉強で仕入れた生半可な知識)って何を使ってるんですかね?←ォイ!
えーと、ログを見ると

あー、これ無いと自前で証明書とか鍵とかを用意しなきゃならないのかな?できんわーw
新しくセットアップする時はこれをチェックしてなかったら入れるようにしよう。

参考サイト:
MacPorts
MacPortsでvariants違いのパッケージをインストールする方法 | 富士山は世界遺産
homebrew
cURLのCA証明書 – There’s an echo in my head
手動
GITGITにしてやんよ | RONOR.org
決定版をアップロードしたい訳で。git hooks

いそいそと本番環境に適用しようとして気付いてしまいました。
うっかりdevelopとかの作業中のブランチに居るのに、masterに居る気まんまんでアップロードしたらいやだなぁ。
リモートリポジトリからpullだけをして来るgit-ftp専用のローカルリポジトリを用意したら安心なんじゃ?!ということで!!
そこで颯爽と登場するのがgitのフックであるpost-updateです。
.gitのhooksの中にあるpost-updateを使って、リモートリポジトリのmasterブランチにpushのタイミングで、git-ftp専用リポジトリからのpullを自動発火させます。

ほんとはこれ冒頭でうらやましがってたように、リモートリポジトリがレンタルサーバ上にあって、そのまま直に公開用リポジトリへ!だったら一番いいのですがねw
ま、贅沢は言いません。これでもかなり便利ですから。

参考サイト:
C-limber’s high: gitのブランチのpushで本番環境とテスト環境への反映を切り替える
gitでhookを使ってWebサイトの自動更新 | 半年前の私への教科書

最終データであるmasterブランチからgit-ftp専用ディレクトリへpullだけもよかったんですが、作業中debelopブランチのプレビュー用(ローカルサーバ上にview.local.com)もついでに作る事にしました。
まず、post-updateを作成。

中身。参考サイトさんを参照して、このような感じに分岐。書き方さっぱりわからん。まねっこ。

post-updateにリネームして保存。
post-updateに実行権限を付ける。

できた!これで安心git-ftp(∩・ω・)∩…でも、Lan上のサブマシーンからpushすると発火しない。
どこよ?ないよ?ftp_stagingとかに移動できないよ。と怒らりる。
うーんそうだよね。実行してるのは、別のマシーンでそのマシーンには/Users/ojiroないもんね。
否、プログラムを動かす実行権ないもんね…よく考えたらただのファイル共有でした。サーバもただのファイルサーバーだしw
ありゃーお手上げです。
masterとdevelopにpushするのは、メインマシーンからだけになっちゃいました。
いいんです…しばらく画面共有からpushしたいと思います。
もうちょっと勉強して、違うプロトコルから試してみようか否か( ´・ω・)。

追記:ローカルのマシン全部からpost-updateを発動させたい訳で…

#この記事を書いた人のリモートリポジトリはローカルのMac上にあるのです。
sshを使うことにしました。結局これが一番近道でした…orz

参考サイト:
Macにgitサーバーを構築してgit://(gitプロトコル)でアクセスできるようにする方法 | Macとかの雑記帳

↑こちらをすごく参考にしたらできました(∩・ω・)∩。ペコ

しかし、近道にもこんな障害が!
普段は文句言わないのにsshだと、git-receive-packが見つからないだとか→
~/bashrcで/opt/local/binへのpathを通す。(/opt/はMacPortsでgit-core入れた場合。)
私の環境の場合、~/.bash_profileで通してもダメで、~/.bashrcだと通る。
MacPortsを使ってインストールすると~/.profileにpathが自動で設定されるらしいんだけど、読み込み順位は~/.bash_profileより下。始めに見つけたやつだけ読み込まれるので.profileは読み込まれないことになる…色んなもののPathが切れちゃう。
それ以前に、sshでスクリプト経由の非対話モードだと~/.bash_profileが読み込まれないらすぃ…。
~/.bashrcで通ってるので現状これで好しとして、一応後学の為にenvironmentというキーワードをメモっておくだす。
pathを通すって人生で初めてやりますたよ。

参考サイト:
Mac を git の共有レポジトリにする — BONNOH FRACTION 14
Macで git push したら git-receive-pack: command not found のエラーが出たときの対処法 | わすれないように.
[ssh] ssh経由で他のサーバのスクリプトを実行するときに.bash_profileを読ませる方法 – It’s raining cats and dogs.

Permission denied (publickey,keyboard-interactive)だとか→
post-updateでpullする側のoriginのアドレスが間違うていたという凡ミスですた。
クライアント機とサーバ機を混同してssh経由のアドレスを設定してました。
私の場合はリモートリポジトリとローカルリポジトリが同機にあるので、/Users/ojiro/~ という素直なパスで良かったのでした。

webのみなさんありがとう〜

2014.04.15

ご飯が白いのよ!〜git branch

サイトを更新していて失敗することってありますよね。実験的に書いてみたスクリプトが動かなかったり、変更したレイアウトが気に入らなかったり。
今までは元に戻すためにこの地点までのバックアップをデスクトップに置くなどしてました。
しかし、居間でヌクヌクするためにgitを導入してから、元に戻すことを想定したバックアップが不要になりました。

なんとなく使えるようにはなった。けどなんかルールがいるよね?

色んな入門サイトをはしごして、なんとか自分のサイトをgitで管理できるようになりました。感謝。
しかし、2台のマシーンで開発するにあたってコンフリクトが多発w。ちょっと覚えたてのrebaseをいい気になってpush済みに使ってぐっちゃぐっちゃになってみたりもしました。
一人でやることといえ運用方針を決めておかないと「あれ?どっちのマシーンで何をしたっけ?あーコンフリクトぉぉぉぉ!」という泥沼に時間を吸い取られることになってしまいます。
そんで、こちらを参考に運用してみることにしました。

参考サイト:
見えないチカラ: A successful Git branching model を翻訳しました
ご飯が白いのよ!

とりあえず常時使うブランチは3つほどにして緩い感じで慣れて行こうと思います。

  • masterブランチには完全版しか上げません。
    常にdevelopブランチからしかmergeしません。
    常設のブランチ。
  • developブランチを開発に使います。
    常設のブランチ。
  • featureブランチは不安要素がある場合、もしくは進行してる作業に別案が出た時の比較をmaster,developからブランチを切り行う。
    mergeはdevelopのみに行う。臨時のブランチ。

A successful Git branching modelはもっと複雑で目的に応じた多くのブランチを扱います。こんな簡単じゃないです。やって行くうちにこのbranching modelの言わんとしてることが分かってくるかなと自分に理解できる必要な所だけ端折ったり統合したりしてみました。
でも、これだけ簡単な応用でもcheckoutとmargeの経路というか制限は非常に役に立つのではないかと思っています。
では、ひよこで想定してみたいと思います。

へびちゃんはdevelop界でひよこにごはんと納豆とネギとしょうゆを与えました。
nevaneva
失敗です。ねばねばです。しかもネギを可愛いがっています。ひよこに納豆ごはんの作り方を教えなかったからです。
neverboo
納豆だけを先に食べてしまったひよこは、ごはんが白いと食べられないと文句を言いますがへびちゃんは別にいいんじゃね?と思います。
何事も経験です。おなかが空いたら白いごはんもおいしいのです。

へびちゃんはdevelop界をそのままmaster界という現実にするつもりでしたが、ししちゃんは納豆は手で食べると大変な事になるということを学んだ上で正しい納豆ごはんを食べる世界にするべきだと思いました。
だいたい弟ひよこは納豆食べてませんし、かわいそうです。

しかし、もうdevelop界に納豆はありません。

そこで納豆を食べる前に戻る事にしました。なんたってししちゃんとへびちゃんは神様なのですから。

ししちゃんは納豆だけを食べる前の世界masterから亜空間featureを作りました。ここではまだ納豆は無事です。この地点から納豆を料理します。
nevacook
ひよこはなっとうごはんをたべました。
nevemogu
望ましい結果になったので、develop界の失敗をreset –hardの呪文でなかったことにしてもいいのですが、やはり記憶commitとして残しておくことにします。面白いし。
develop界で、記憶を残しつつ時を戻す呪文revertを唱え納豆を手づかみする前に戻り、時が戻ったdevelop界に正しい納豆ごはんを食べているfeature亜空間を融合mergeします。

develop界の納豆ごはんにもうまちがいは無いか確認して、完全な納豆ごはんを食べた世界を確定します。管理人的にはmasterにdevelopをmergeです。
ひよこはおいしく納豆ごはんを食べることができました。
ねばねばはもうかんべんです。

図にしてみる。
nebazu
結果(ひよこブーイング)が微妙なので、別の過程へ(納豆調理)進路をとり、結果(もぐもぐ)を比較して採用の流れ。

もし、masterにマージしてないコミットがあり、developからしか戻れない場合は

としてdevelopブランチの納豆が無事な所まで戻ってでfeatureブランチにチェックアウト。

蛇足ですが、最初このcheckoutが理解できませんでしたw
だって、checkoutってなじみ深い単語ですよね。ホテルの部屋をチェックアウトする。とかoutなんです。出てゆくんです。
masterブランチに切り替える時に『masterブランチをcheckoutします』という説明がけっこうあります。
えっ?今、masterに居ないんだけど?masterを出てゆくの?
ってなりません?

と脳内補完して覚えましたw

本家modelでは、リモートリポジトリに上げるのはmasterとdevelopだけなのですが、私一人用のシステムなのでfeatureもリモートに上げて、別マシーンでpullして作業の続きをしたりしてます。
実はローカルな構築でhooksを使う際にちょっと不便な点があったりして始めたmodelなのですが、なかなかいい感じです。

2014.04.15

自宅を流離うのにgitを使う事にした。

nebazu
MBPをぬくぬくな居間で使う為に色々試行錯誤をしているうちにだんだん春になってきました。
しかし、そこは北国。まだまだ雪がありますよ。へたすりゃ積もらないなりに降ってますよ(´・ω・)。
そして、やっぱり部屋寒い。
ということで、あたたか〜い居間からサイトを制作するためにAptana Studio3をそれぞれのmacにインストールして、gitでサイト管理を始めました。

ほんとはAptanaのワークスペースを共有したいだけだった

そもそもgitが何か分からないのに導入しようとした動機は、ヴァージョン管理が目的というよりは愛用のAptana Studio3のワークスペースをサブ機から共有できないことからでした。
(それぞれマシーンのAptanaごとに.metadataが作られ、共有したいワークスペースにはもうメイン機の.metadataがあるわけでして。あ、だめじゃんこれ。と早々に退散。)

分散型管理って何?
同じデータをそれぞれのマシーンに置き、それぞれの変更を同期をとりつつ管理できるという仕組みかなぁ。
リモートリポジトリというものを共有して、そこにデータを上げたり、取ってきたりするのか。と適当に理解。
JQueryとかZencodingとかのバンドルをダウンロードするためだけにあるんじゃないんだ!これ!という事で、メイン機にはgitもう入ってるし使ってみることにしました。

小難しいことは後からするとして、とりあえずlocalプロトコルで(何の事はない普通にファイル共有)自分のLan内だけだけど、ぬくぬくの自宅モバイルが前提ですからね十分(・ω・´)。
それに、gitを使うようになっていい事が沢山ありましたよ。

gitのインストールはどうだったけ?

win版ではデフォルトで簡易版gitが付いてくるらしいけど、Macの人はgit本体を自分で入れなきゃなりません。
Snow Leopardの時はXcodeを入れて…MacPortsを入れて…MacPortsからgit-coreを入れて…という、特にXcodeを入れるのに気の遠くなるような作業が必要でした。

参考サイト:
【Mac】OS X10.6.8にXcodeをインストールする: なんとなくかいてみる
Cocoaの日々: MacPorts と git インストール

Lionの時も同様の手順を踏んでいたような気がするんですが、Apple DeveloperからCommand Line Toolsを単体で入れられるようになったようです。
Xcodeの行程をすっ飛ばせるってすばらしい。でも今はXcode簡単にAPP Storeから入手できますね。

新しいMBPのMavericksではgitのインストールは恐ろしいほど楽チンでした。
Aputanaをインストールする時、Command Line Toolsが要るし!インストールする?とか気の利いたアラートがでて、入れたらCommand Line Toolsにgitも入ってました。(Xcodeは入れませんでした。MBPには容量でかい…)
Command Line Toolsのgitは(Apple Git-xx.x)とかになり、本家gitよりバージョンの更新が遅かったりするようです。常に最新版を使いたくなったらHomebrewなどでインストールし直そうと思いますだ。

参考サイト:
Macのgitをhomebrewでインストールしたものに変更する – Rock’n’Hack ブログ

ただし、Aptanaの設定もどっかいじらんとダメかもしれない。それはその時また…

gitの準備をする

今までもサイト構築に使っていたメイン機にはAputanaのワークスペース内にオリジナルのプロジェクトフォルダがあります。
このフォルダをそのままgitリポジトリにしました。

オリジナルのプロジェクトフォルダにgitリポジトリを設置

ターミナルからプロジェクトフォルダに移動して

リモートリポジトリはまだ無いけど、作る予定の所のパスを設定。

その他、自分の情報を設定しておく。これは–globalにしておくと便利。

プロジェクトフォルダの中に元々あったhtmlやimgフォルダなどをgitの管理下に置く。

共有するリモートリポジトリを作る

プロジェクトフォルダがあるのと同じメイン機にリモートリポジトリを作りました。HDD換装したから容量あるしぃ〜でも分散してないw。

wainoprojectディレクトリに移動してリモートリポジトリとなるwaino.gitフォルダを作る。拡張子.gitは必須。
リモートリポジトリにはinitにオプションをつけます。

–bareは内容のファイルとかを作らないgitのデータのみの生?のリポジトリを作る。
–sharedをつけるとややこしいパーミッションを良きに計らってくれる。共有するために必要。

無事にリモートリポジトリができたので、オリジナルのプロジェクトフォルダに戻ってpush!

色々な表示がだらららーっと表示されて、できたよ!っぽいメッセージが出るけど、リモートリポジトリにデータが無事にpushされたかどうか心配だったりする。
次のcloneで安心できるよ!

サブ機にクローンしてローカルリポジトリを作る

居間で使うサブ機MBPにAputanaのワークスペースを作って置き、ここにリモートリポジトリからデータをクローンしてくる。
サブ機で使うusernameとmailを設定。メイン機と違う名前にしたほうが後々commitなど管理しやすい。

ワークスペースにしたディレクトリに移動して

作られるディレクトリの名前を変える場合は、スペースを一つあけてbetuno名前を入れる。
色々な表示がだらららーっと表示されて、できたよー!っぽいメッセージが英語で出たら、成功。
cloneして来たリポジトリには最初からremoteの場所の設定もされている。
Finderから見てみるとメイン機のオリジナルのプロジェクトフォルダ(ローカルリポジトリ)と全く同じように材料が揃ってる。わーい(∩・ω・)∩

Aputana Studio3でgitを使う

サブ機でAptanaを開き、通常通りプロジェクトエクスプローラー>ローカルファイル・システムからcloneしてきたフォルダを辿り、右クリックでpromote to project…を選び、プロジェクトにすると…
いきなりAptanaのGUIでgitが使えるようになってます。はー出来た(∩・ω・)∩

もちろん、最初にリポジトリにしたオリジナルのプロジェクトもgit仕様になってます。横に[master]とか出てます。
Aptanaから直接操作してリポジトリを作ったりしたことはないのですが、Aptanaでやらない方が簡単な予感…

apt_git800
文字化けやスペルミスありますがtest画像。

最初はターミナルの使い方を最低限でも覚えようと思ってMac本体のアプリケーション>ユーティリティ>ターミナルを使っていたんですが、Aputanaにもありましたターミナル。git入れる時使った…そういえば。
ウィンドウ>ビューの表示>ターミナルで下のカラムに表示させてます。

コマンドを打ち込まなくてもプロジェクトエクスプローラーは右クリック>チームで、APP Explorerからはバーから直接or右クリックで基本的な操作が出来ます。
変更してまだインデックスにaddしてないファイルや、未コミット、未プッシュもエクスプローラー上にマークされるので便利です。

”リソースヒストリー”ではファイルごとのコミット履歴も見られます。ただ、全体の履歴の見方がわからないので、ターミナルからlogとか打ち込んだりしてます。
ターミナル上でcheckoutとかするとなかなかExplorerで表示が切り替わらなかったり少々難はありますが、全部が全部AptanaからGUIの操作をしようと思わなければ、なかなか使えるのではないかと。
EGitとか入れたらどれだけ便利なんだという世界です。
しかし、EGit。
ヘルプ>新規ソフトウェアのインストール>URL入力 からインストーラーまでは辿り付けるのすが、なんか足りないってAptanaに怒られてインストール出来ないので、しばらくはこのデフォルトの機能とターミナルでしのごうと思います。そんなに大した事してないもん…な

以上、git備忘録でした。まだまだ続くよ(`・ω・´)

PageTop