TIM Labs

2010年11月アーカイブ

gitでは様々な方法でコミットログを書き換えることができます。 その一例として複数のコミットを1つにまとめる方法を紹介します。

問題

先日紹介した gitでコミットの順序を入れ替える 例ですが、 そこでは以下のコミットログを:

$ git log -n 4 --oneline --reverse
0000001 Add a neat feature X into the library
0000002 Update to use X
0000003 Fix a typo in X
0000004 Fix a bug in X

以下のような形になるよう順序を入れ替えました:

$ git rebase -i HEAD~4
Successfully rebased and updated refs/heads/topic-x.

$ git log -n 4 --oneline --reverse
0000001 Add a neat feature X into the library
a000003 Fix a typo in X
a000004 Fix a bug in X
a000002 Update to use X

ここで0000002はアプリケーション側に対する変更で、 それ以外の3つはライブラリ側に対する変更です。

順序的にはこれで良くなったのですが、 このコミットログはコミットログでやはり悲しいものがあります。 人間、誰しも見栄っ張りなので、 対外的にはしょうもないタイポやミスの修正コミットは見せたくありません。 この変更はまだまだどこにも公開していないので、 いまのうちにコミットログを書き換えることにしましょう。

この場合、しょうもない修正コミットはa000003とa000004です。 この2つを0000001に合成して最初から完璧なコミットができていたことにすれば よりコミットログが美しくなります。 しかし具体的にはどうすればよいでしょうか。

最初にお断りしておく。 本記事は恐らく実際に使用することは滅多にないと思われる類の話である。 要は自己満足系の何かで、使うにしても本当に必要なのかどうかちゃんと考えるべきだ。

でも単純に楽しいんだよね...。

さて、STLのstd::pairは、普通要素にアクセスするときは first、second でアクセスする。 しかしこれ、実に味気ない名前であって、汎用性があるといえば聞こえはいいが、 どっちに何が入っているか把握していないといけない。 そんなわけで、名前がつけられたらいいなあ、なんて思うワケだ。

gitでは様々な方法でコミットログを書き換えることができます。 その一例としてコミットの順序を入れ替える方法を紹介します。

問題

とある新機能Xを追加することになったとしましょう。 まずはこの作業用のトピックブランチを作成します:

$ git checkout -b topic-x master

新機能Xの実装をします。まずはライブラリ側の方を修正して:

$ $EDITOR library.source
$ git commit -am 'Add a neat feature X into the library'

次に新機能Xを使うようアプリケーション側の方をします:

$ $EDITOR application.source
$ git commit -am 'Update to use X'

と、ここで終われば良かったのですが、 大抵の場合、この段階でしょうもないタイポやミスが発覚することが多いです。 仕方がないので直すことにします:

$ $EDITOR library.source
$ git commit -am 'Fix a typo in X'
$ $EDITOR library.source
$ git commit -am 'Fix a bug in X'

これまでの作業を確認すると以下のようになっています:

$ git log -n 4 --oneline --reverse
0000001 Add a neat feature X into the library
0000002 Update to use X
0000003 Fix a typo in X
0000004 Fix a bug in X

このままmasterにmergeしてもいいのですが、 さすがにこのコミットログは後から見返したときに悲しくなります。 まだこの作業内容自体はどこにも公開されていないので、 いまのうちにコミットログを綺麗な形に書き換えるとしましょう。

この場合、0000002を最後に移動すれば、 最初の方がライブラリに対する変更で、 残りがアプリケーションに対する変更になるので、 上記の順序よりは綺麗になります。 しかし具体的にはどうすればよいでしょうか。

シェルスクリプトなどで、「今自分自身が設置されているディレクトリ」を取得したいと いうことはよくある。その後の処理を全てスクリプト位置からの相対パスで行うことで、 設置位置やカレントディレクトリとの依存関係を切り離すためだ。

gistはweb上でソースコード(の一部)を共有したり、再利用するためのwebサービスです。

設定ファイルの書き方やプログラムのわからないところを聞くときなど、コードの一部を共有したいという欲求はコンピュータエンジニアであれば誰もが遭遇することと思います。これまではIRCやブログのコメント欄にソースコードをコピペするなどしていたわけですが

  1. シンタックスハイライトされない (色ついてないと読み辛いです......!!)
  2. 行番号が表示されない (どの部分を見ればいいのかわかんないです......!!)
  3. 貼り付けられているものをファイルとして取得するのが面倒 (これそのまま自分の設定ファイルにしたいのに、変なスペースが入ってきちゃった......!!)
  4. 再編集したものを共有できない (バグ直したけどどうやって教えてあげたらいいの......!!)

etc... といった問題がありました。

gistを使えば全ての問題が簡単に解決します。 リンクを開いて画面上のテキストエリアにコード片をペーストし、[create public gist]ボタンをクリックするだけです。

このように、ブログに埋め込むこともできます。

シンタックスハイライトはC、Perl、Python、Ruby、PHP......といった主要な言語に対応しています。

view raw リンクから生のファイルとしてダウンロードすることもできます。

gitを使っている人なら更に便利に使うことができます。一個一個のgistはgitリポジトリになっているので、自分のマシン上にcloneすればweb画面からではなく自分の好きなエディタで編集してそのままpushすることができます。


実はgistはこれ単体で一つのwebサービスではなく、githubの一機能となっています。githubはgitリポジトリのホスティングサービスで、JavaScriptやRubyのライブラリや数々のオープンソースのプロダクトがこのサービスを利用してソースコード管理を行っています。

gistにはソースコード管理機能だけではなく開発者同士が繋がるSNS機能が盛り込まれており、開発者同士の連携をとりやすくなっています。gitやgistが便利だと感じたらgithubの利用も考えてみてください。

cronはUNIX系システムでタスクの定時実行を行うためのツールです。どのUNIX系システムでもまず間違いなく入っているので、システム開発の際でもよく使いますが、古いUNIX由来のツールにありがちなバッドノウハウに嵌ったのでご紹介します。

crontabのコマンドを指定するところで%(パーセント記号)を使うときは\でエスケープする

日付つきのファイル名でログを保存しておきたくなることや、コマンドライン引数中に%を使いたくなることがたまにあります。dateコマンドを使う場合には、次のように書きたくなるわけですが、これはうまく解釈されません。

0 0 * * * wonderful_command > log_of_`date +%Y%m%d`.txt

(そうです、あのウザいメッセージがプロンプトの上に延々と表示されることになります! You have new mail. You have new mail. You have new mail. You have new mail. You have new mail. You have new mail. …)

crontabのコマンドを指定するフィールドで%を使うと、最初の%以降は標準入力に対する入力して解釈されます。%そのものを使いたい場合には(バックスラッシュ記号)でエスケープする必要があります。

上の例はこんな風に直せば、期待通りに日付つきファイル名でログが保存されることになります。

0 0 * * * wonderful_command > log_of_`date +\%Y\%m\%d`.txt

これがどこかの仕様として決まっている動作なのかは調べることができませんでした。現在一般的なcronの実装であるvixie cron のmanには次のように書かれています。

The “sixth” field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab file. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input. There is no way to split a single command line onto multiple lines, like the shell’s trailing “\”.

(フォントの都合で円マークとバックスラッシュが混じって表示されているかもしれませんが、同じ文字を意味しています)

普通プログラムといったら、なんらかの入力データに対して処理を行うものだ。 しかしまあこの入力データというヤツ、大抵の場合信用できない。 というか、「いいよ信用して」と言われていたとしても、疑ってかかるのがセオリーだ。

そんなわけで、基本的に入力値というものに対しては、殆どの場合 それから行う処理に対して適切なものかどうかというのを確認することになる。

その中でも基本的なものが、「未入力判定」だ。 そもそもデータが存在していなければその先の処理ができなかったり、 意味がなかったりということは良くある。 だから、必要なデータが存在しているかどうか確認する場面というのは数多くある。

じゃあ、そんなときPHPではどう書くか?

IT技術者集団のタイムインターメディアには、様々な技術を必要とする開発案件が持ち込まれます。特殊な技術を必要とすることもあれば、時代の新しい技術トレンドあり、また、高信頼性、高速性などいつの時代にも要求され続けている技術も要求されます。

これらに対処するため、さらには技術者自らがより高い技術を求めて、様々な調査、研究、実験などを行っており、それらを通じて得られた、他の技術者にとっても有用ではないかと思われるものを情報発信していきます。

オープンソースの公開、勉強会などを会社創業当時より開いてきましたが、さらに、本技術者ブログにより、IT技術者達が何を考え、どんなことをしているか、その一端を理解していただき、一緒にITの未来像を描けたらと思っております。

タイムインターメディアは、ITの特定分野に特化した会社ではなく、技術者各自が、様々な技術を追いかけているので、多様な内容になってしまうかと思いますが、これからの時代、多様性こそ重要であり、興味のある部分を見出していただければと思います。

このアーカイブについて

このページには、2010年11月に書かれたブログ記事が新しい順に公開されています。

次のアーカイブは2010年12月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。