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