読者です 読者をやめる 読者になる 読者になる

gitの使い方

少しはgitに慣れてきたと思うので、使い方を書こうと思う。うまく行ってることとか、失敗したなぁと思ってることとか。

今、念頭に置いているのは、ユビレジ。サーバサイドとクライアントサイドで別れてて、サーバはRails、クライアントは普通にXcodeとかで書いてる。

githubリポジトリは分ける

これはcapistranoの影響が大きい。capistranoはgitリポジトリのルートにRailsのアプリがいることが前提になっているので、どうしてもサーバをわけざるをえない。まあ、クライアントをディレクトリ掘ってその中に入れちゃうという案はある。

githubの課金アカウントが必要とかそういう話もあるけど、分けてて失敗したと思うのはIssue Tracker。どっちのIssue Trackerに登録するのか迷うことがけっこうある。そもそも、githubのは使い難いので最近はあんまり使ってないのが現状で、結局べつに良い気もするけど。

本番サーバで動いてるやつを格納するreleaseブランチを作る

これは私がうっかりミスしたのが原因でもあるんだけど。

大体、masterからトピックブランチを作って作業してる。で、普通はmasterをそのままデプロイでも良い気がするんだけど、最近releaseブランチを作った。

releaseブランチを作っておくと、なんかやばいバグが見つかったので急いで直したいんだけど、masterはまだ公開するつもりがないトピックブランチをマージしちゃったやつが残ってて、デプロイできないのでさあ困った!みたいなときに対応できる。releaseだけちょろちょろっと直しちゃって、そのままデプロイすれば良い。そうしておいて後でmasterにgit cherry-pickする。

ただし、そもそもmasterに公開できないものが入っちゃうのがおかしいという説もあって、それももっともなんだけど。でも、当初のスケジュールだとさっさとリリースしちゃう予定で、まあいっかって思ってmasterにマージしたけど、いろんな事情でリリースの予定が延びちゃってなんかそのままmasterが中途半端、みたいなこともきっとけっこうあると思う。

ちなみに、急遽releaseブランチを作ってデプロイ、なんてことになったわけだけど、そのときはサーバで動いてるのがどのバージョンなのかすぐに判別する方法が無さそうでちょっと途方にくれそうになった。正解は、capistranoが作ってるリポジトリのcloneを見つけてgit logすることだった。

その他

gitkが何気に便利。ブランチで作業してるときには、どのブランチで作業してるのか、一目で見れて便利。ブランチ増えてくるといろいろグラフが複雑になってきて楽しいし。

困ってること

migrationをどうするか微妙に悩んでる。

どうせgithubにpushするときにはmasterにmergeするので、関係ないといえば無いんだけど、ローカルで作業するときにトピックブランチでマイグレーション作っちゃうと、ブランチごとに眺めてるとなんかそのうち不整合が起きそう。