gitで仕事する生活。

手元バージョン管理を全部gitにしてからはや数ヶ月。最初はいろいろとまどったが、案外慣れてしまうものだ。 まず仕事方面。いろいろな都合から会社の中央レポジトリはSubversionなので、gitはgit-svnと共に使っている。最近の仕事はどっぷりLinuxで、gitでさくさくfeature branchを切りかえて作業ができるのは実によい。 仕事で相手をしているSubversionのレポジトリはtrunk/branches/tagsの標準的なスタイルなので、git svn clone時には-sをつけて、リモートのsvnブランチもローカルのgitのブランチとしてcloneしている。 git svn clone -s (subversionのURL) hoge このcloneはかなり遅いが、まあ、一度作ってしまえば、あとは適当に[cci_bash]git svn rebase[/cci_bash]してゆけば更新されるのでさほど困りはしないはず。 さて、そうやってcloneしたレポジトリの上で、何か機能を作りこむ必要があるときは、 git checkout -b hogehoge と作業ブランチhogehogeを作って作業し、確認が終わったら git checkout master して、git svn rebaseして、おもむろに、 git merge --squash hogehoge あるいは git merge ーno-ff hogehoge としてhogehogeブランチの作業内容をマージしてから最後に git svn dcommit して、またgit svn rebaseしつづける定常状態に戻る。dcommit直前まではsvnのことを忘れていられるのがよい。 自宅環境(Windows&FreeBSD)にはsvnはからまないので普通にgitを使っている。自宅サーバにbareレポジトリを作って、そこにssh経由でpush/pullすることで出先からの取得・更新も可能にしているが、運用練習も兼ねてbitbucketに移動したほうが幸せかもしれないと最近は考えている。 LinuxでもFreeBSDでもWindowsでも、シェルにbashかzshを使っている限りは補完が充実しているので、シェルで使うのが一番だ。ただ、作業はEmacs上で行うので、履歴や差分の確認はEmacs上のEggに頼ることも多い。慣れ親しんだEmacsのvc.elライクなキーバインドなので悩まずに済むのがよい。 さて、コマンドラインでgitを使っていてもコミットメッセージはEmacsを使いたいので、core.editorにはemacsclientを指定している。FreeBSDとLinux上のEmacsは(prefer-coding-system 'utf-8-unix)にしているので何もせずに新規バッファを作ればutf-8になるが、Windows環境は諸処の事情でutf-8を最優先にしていないので何もしないとコミットメッセージが化ける。んで、下記のhookを入れている。 (add-hook 'server-visit-hook (function (lambda () (if (string-match "COMMIT_EDITMSG" buffer-file-name) (set-buffer-file-coding-system 'utf-8))))) 職場でもっとgitとgit svnの啓蒙活動をしたいところだなぁ。

December 2, 2012 · 1 min · 60 words · nekomimist

gitに乗りかえた雑感。

自宅の環境ではMercurialでもBazaarでもそう遅くは感じなかったのだけけれど、まあ、たしかに軽く感じる。会社の環境はアンチウイルスのMcAfeeとの食い合わせが悪くBazaarは使いものにならなかったのがズパズパ動くのは気持ちがよい。 Subversion/Bazaar/Mercurialとの違いとして、管理されているファイルを変更しても[cci_bash]git add[/cci_bash]してステージしてやらないとcommit対象にならないのは面白いと思った。一つのファイルの中のどの部分をステージするかすら[cci_bash]git add -p[/cci_bash]でできる事を考えると、「サボって複数の変更を一つのコミットにまとめてしまうな!」というメッセージを感じるね。 あと、branchとheadが存在が軽いのに戸惑ったりもしたが、便利だとも思う。さっとブランチを作ってその上で開発してmasterにマージして消せるし、[cci_bash]git reset –hard HEAD^[/cci_bash]でhead(とindexとworking tree)が履歴を辿って戻せるというのも新鮮。戻りすぎてもreflogに残っていればまた戻れるので安心。すごい「ポインタ感」。 ちょっと困ったときに、ぐぐると情報がすぐにひっかかるくらい情報が溢れているのはよい。Mercurialはまだよかったけど、Bazaarの情報はホント少なかったのでね。 コマンドはなかなか覚えられないが、コマンドラインで使ってナンボなかんじ。ただ、GitHub for Windowsの割り切り方はそれなりにうまい。Git Extentionsの方がずっと機能は多いのけれど、「どうしてもGUIで見たいものは何か?」と考えると、案外かなりの場合はGitHub for Windowsで足りると思う。どうせ込み入った作業はシェルから作業するからね。

July 3, 2012 · 1 min · 17 words · nekomimist

もうgitでいいや。

自宅のファイル管理環境としてBazaarをしばらく使ってたのだが、どうもあまり流行らない感じだったので、今年に入ってMercurialに乗りかえていた。が、なんかどうもgitの勢いがさらに増している感じがしていて、gitを知らないのはイマイチなのではないか、と思ったので、gitに乗りかえてみた。 まず、mercurialのレポジトリをgitに移行する。レポジトリはFreeBSD環境に全て入っていて、Windows側はすべてそれのcloneなので、FreeBSD環境で移行さえできればよい。portsでMercurialとgitを入れて、hg-fast-exportを使えば、hg-fast-exportの制限にさえひっかからない限りは悩むことはない。うちでは制限にひっかからなかったので悩まずに済んだ。 で、git。手元の環境はWindowsなので下記2点を使っている。 GitHub for Windows Cygwinのgit うちのコマンドライン環境は非常にCygwinに依存しているので、コマンドラインで使う時はCygwin gitを使い、グラフィカルに見たい場合はGitHub for Windowsを使うという感じを目指している。GItHub for Windows 1.0.11でコミットログの文字コードがあやしくなっていたが、現状最新の1.0.12では直っているので問題ないようだ。 さて、GitHub for WindowsのバックエンドはmsysGitなので、つまりmsysGitとcygwin gitの両刀使いになっている。最近のmsysGitはファイル名をUTF-8として取り扱うので、この2つはあまり齟齬なく同居できるはずだ。 GitHubのアカウントも取ったけど、無料の範囲だと問答無用で公開になるのが悩みどころ。そこはbitbucketの方がよいのだよなぁ。

June 30, 2012 · 1 min · 19 words · nekomimist