Stellaqua - TOMの技術日記 このページをアンテナに追加 RSSフィード

2009年09月24日

[][]Redminegitコミットログが取得できない

以前の記事(「Redmineをインストールしてみた - Stellaqua - TOMの技術日記」)の時にRedmineインストールした後、結局まともに使ってなかったんですが、最近ちょっとまともに使い始めています。

Redmineはホントによくできていて使い易くて素晴らしいんですが、使い始めたところで、「リポジトリの画面で、gitコミットログが表示されない」という問題に当たってしまいました。という訳で、せっかくなので情報共有も兼ねて覚え書きを。

見え方としては、リポジトリのツリー自体は見えていてツリーを辿っていく事もできるんですが、ファイル名以外の情報が表示されていなくて、"最新リビジョン"の項目については項目自体がそもそも表示されない状態でした。

で、Google先生にすがりついた挙句に、どうやらgitコマンドでカラー表示させていたのがよくなかったっぽい事が判明。

そこで、

git config --global color.branch always

git config --global color.diff always

git config --global color.interactive always

git config --global color.status always

みたいにして、常にカラー表示しようとするんですが、

そうすると、周辺ツールなどで予期しない結果がアプリにわたってしまうためか不具合がおきます。

例えば、redminegitリポジトリを使うと、コミットログが反映されなかったりします。

バージョン管理システムについて語るスレ4

普段、gitの設定は上記のように"always"でカラー表示するようにしてたので、どうもこれでビンゴっぽい。

カラー設定を"auto"に変えてあげたら、無事にRedmine上でコミットログが表示されるようになりました、めでたしめでたし。

2009年04月30日

[]WEB+DB PRESSGit特集が素晴らしい

今日は初のN700系新幹線でのネット接続デビューを果たしまして、新幹線の中で記事を書いています。ネットも自由に使えて、コンセントも使えるし、かなり快適ですね〜。( ̄ー ̄)

で、本題。いつも発売日に買っているWEB+DB PRESSを、訳あって今頃やっと手に入れたので、早速読みたいと思っていた、濱野さんのGit記事を読みました。

ざっと読んだ中で一番印象に残ったのは、"注1"でした。(そこっ?!)

http://git-scm.com

なお、英文の文頭に立つ場合に「Git」と書く以外には、システムとしてのgitの名前は「git」と小文字で書きます。本特集でもタイトル以外では「git」と表記します。

"git"を"ギット"と読む事を初めて知った時以来の衝撃でした…。今まで意識して必ず"Git"って書くようにしてたのに…。これからはちゃんと使い分けるようにしたいと思います。

んで、本文の感想ですが、以前、git勉強会で話して頂いた内容を実例を増やして更に掘り下げて書いてある感じですね。今までネットで調べてきた範囲で知らなかったコマンドオプションとかもあったので、参考になりまくりでした。

とは言え、1つ1つは「おぉ、なるほど〜。」とは思うものの、実際に開発現場で使っていかないとなかなかスムーズには使いこなせなさそうです。

特にブランチを使った開発は、きちんと頭の中でブランチツリーを思い描きながら進めないと混乱しがちなんですが、今回の特集でかなり分かりやすく書いて下さっているので、また読み返しつつ、練習もしていこうかなと思います。

2009年04月17日

[][]Gitを触ってみるよ その7「GitHubに公式ITSが登場」

Gitは非常に優れたバージョン管理システムではあるものの、BTS(Bug Tracking System)/ITS(Issue Tracking System)との連携はまだいまいちだなぁ、と個人的に思っていたんですが、GitHubに公式にITSの機能が追加されたようで、ちょっと触ってみました。

no title

今回はお試しなので、適当な空リポジトリを作って、それを使ってIssueの自動クローズなんかを体験してみたいと思います。

実験用リポジトリを作成する

GitHubにログインして、"Create a Repository"で新規リポジトリを作成して、後は表示される手順に従って作業を進めます。具体的には以下のような感じ。

$ mkdir its-test
$ cd its-test
$ git init
$ echo 'マージできたよ!!?' > README
$ git add README
$ git commit -m 'first commit'
$ git remote add github git@github.com:stellaqua/its-test.git
$ git push github master

こういった、次に何をすればいいのかという手順をちゃんと示してくれるのが、GitHubの素晴らしいところですな。

ITSにIssueを登録する

GitHubの画面に戻って、今作成したリポジトリの"Issues"タグを見てみます。

f:id:stellaqua:20090417131952p:image

"Create Issue"のボタンを押して、いくつかIssueを作成してみます。

f:id:stellaqua:20090417131951p:image

作成したIssueの一覧表示はこんな感じ。デフォルトだとPriorityでソートされています。*1

f:id:stellaqua:20090417131950p:image

タグ付け(Labels)も自由にできて、タグによる一覧表示の絞込みもできるので、機能群毎にIssueをグループ分けしたりすると便利かもしれないですね。*2

コミット時にIssueを自動クローズしてみる

Track & Subversionでよくやるような、コミット時の自動クローズにも対応しています。

$ echo 'やぁ、ぎっとたん。githubにあげてよ!' >>README
$ git add README
$ git commit -m 'Add 2nd message.Close #1'
$ git push github master

コミットメッセージにIssueの番号を入れておくと、コミット時に該当Issueが自動的にクローズされます。

f:id:stellaqua:20090417131946p:image

ちゃんとステータスがClosedになりましたね。

では、残ったIssueも片付けてしまいましょう。

$ echo 'もうpushしてるよ' >>README
$ git add README
$ git commit -m 'Add 3rd message.Close #2'
$ echo 'くろーん(´・ω・`)' >>README
$ git add README
$ git commit -m 'Add last message.Close #3'
$ git push github master

という事で、今回のプロジェクトは無事に完遂できました。めでたし、めでたし。

使ってみた感触とか

Trackみたいに機能が豊富って訳ではないですが、逆にシンプルな分、結構お手軽に使えて良い感じですね。

実際使う時は、Issue毎にブランチを切って、masterにマージする時に該当Issueをクローズする…ってやるのが良さそうな気がします。

世間的にもGit熱は益々過熱しているようなので、Gitの今後の動向から目が離せませんね!

余談

今回サンプルとして作成したREADMEのセリフは、以下のトコの漫画から拝借させてもらいました。

くろーん - #生存戦略 、それは - subtech

どうにも「くろーん…」が可愛すぎて、どうしてもネタにしたかったんです。(笑)

やっぱりCDD(Character Driven Development:キャラクター駆動開発)って大事ですよね。( ̄ー ̄) これで、"Git"の読み方が"ぎっと"だという事が広まってくれる事を願いつつ、今回のGitネタはこの辺で…。

*1:Priorityがどこで設定できるのかは分かりませんでした…。

*2:元記事の紹介ビデオを見るとLabelに色を指定する事ができるようなのですが、Operaだと対応していないのか色指定できませんでした。使えなかったのがブラウザのせいなのかどうかは調べた訳じゃないので不明です…。

2009年04月07日

[][]Gitを触ってみるよ その6「普段よく使うコマンドの覚書き」

普段よく使うコマンドたちを、よく使っている内に覚書きとして残しておくテスト。

初期化・初期設定

ローカルでバージョン管理を始めたかったら、とにもかくにも"git init"。

$ cd /path/to/project
$ git init

diff結果やログをカラー表示させたい場合は、以下のコマンド。

$ git config --global color.branch always
$ git config --global color.diff always
$ git config --global color.interactive always
$ git config --global color.status always

"--global"で設定すると、多分ユーザ毎の設定になるので、1回実行しておけば次回以降は不要だと思います。

更新・コミット

ソースコードに更新を掛けたら、以下の要領でローカルリポジトリコミットします。

$ cd /path/to/project
$ git add .
$ git status
$ git commit

"git commit -a"だと、新しく追加されたファイルは更新対象にならないので、ファイルを追加したかどうか気にするぐらいだったら、毎回"git add ."した方がいいかなと。

あと、"git add ."した後に必ず"git status"として、ファイルの更新漏れが無いか確認しておいた方がいいかなと。以下のように"git status"で見た時に赤で表示されるファイルは、更新対象から漏れているものです。

f:id:stellaqua:20090407210047p:image

特に、自分でrmとかでファイルを削除してしまった時は、以下のようにキャッシュ上のファイルを自分で削除する必要があります。

$ git rm --cached file2

rmで消さずに、"git rm file2"などとすれば、ローカルファイルとキャッシュ上のファイルを同時に消せるのですが、自分の場合は、いちいち"git rm"にすべきかどうか考えるのが面倒なので、消す時はrmで消してしまって、上記のようにコミットの際に必要になった時だけ、"git rm --cached"で消すようにしています。

ファイルの状態を戻す

ローカル上のファイルをキャッシュ上の状態に戻すには以下のコマンド。

$ git checkout file

"git rm"してしまっているとキャッシュ上のファイルも消えてしまっている為、この方法では戻せなくなってしまうので、そういう意味でもファイルの削除はコミット時だけにしておくのが良いかなと。

ちなみに、コミットした後でも何回か前のコミット状態に戻す事もできます。キャッシュとローカルの両方を戻す場合は以下。

$ git reset --hard HEAD^

これは、最新のコミットの1つ前のコミットの状態に戻す場合。"--hard"を"--soft"にすると、キャッシュのみ状態が戻って、ローカルは現状維持になります。

ちなみに、最新のコミット状態より後にファイルが追加されて、まだ"git add"されていない場合、"git reset --hard"でも、追加される前の状態(ファイルが無い状態)にはならないようです。

"git reset --hard"する場合は、とりあえず一旦コミットはしてしまって、クリーンな状態で行った方が混乱が少なそうです。

"元に戻す"操作に関してはCodeReposのFAQが分かりやすくて参考になります。

no title

ブランチ

ブランチを新しく作って移動するには以下のコマンド。

$ git branch test1
$ git checkout test1

ブランチの移動で切り替わるのは飽くまでコミットの状態である事に注意。ローカルやキャッシュの状態はブランチを移動しても引き継がれます。

ブランチでの更新をmasterに反映させるには以下のコマンド。

$ git checkout master
$ git merge test1

単純にマージした場合は、ブランチ上で行ったコミットが全てマージ先に反映される事になります。

ちなみに、ブランチでの更新を一括して一つのコミットとしてマージしたい場合は、以下のようにします。

$ git checkout master
$ git merge --squash test1
$ git commit

これを使えば、ブランチ上でガンガン更新、ガンガンコミットしまくれて、とりあえずで適当なコメントでコミットしておいたりしても、そういった汚い部分は表に見せる事なく、最後にしれっと素敵なコメントだけ残してマージする事ができます。


ローカルでの作業に関してはこんなところですかね。

リモートリポジトリの作り方なんかは、以前記事を書いたので、そちらを参照。

Gitを触ってみるよ その3「集中管理型リポジトリの作成」 - Stellaqua - TOMの技術日記

また便利な使い方を覚えたら追記しようかと思います。

2009年03月14日

[][]Gitを触ってみるよ その5「分散型バージョン管理システムによる開発って生物の進化っぽい」

Gitの仕組みを勉強するにつれて思っていた事なんですが、分散型のバージョン管理システムで進める開発って、何だか生物の進化みたいだなと。今回はそんなお話です。

分散型バージョン管理システムって?

本編の前にまずはおさらいという事で、「分散型バージョン管理システムって、何ぞや?」というところから。本シリーズで散々Gitを使ってきているので今更なんですが、自分的なまとめの意味も込めて、改めて…。

今のところ本シリーズでは、どちらかと言うとSubversion的な集中管理型の使い方をしてきました。

f:id:stellaqua:20090314194157p:image

こんな感じですね。

分散型になるとどうなるかというと、こんな感じになります。

f:id:stellaqua:20090314195655p:image

開発の流れとしては以下のような感じですね。

  1. Aさんが自分のローカルリポジトリ上で開発を進める。
  2. 公開したくなったタイミングで公開リポジトリにpushする。
  3. Aさんの公開リポジトリを見て気になったBさんが、自分のローカルリポジトリにソースコードをcloneしてくる。
  4. Bさんは自分のローカルリポジトリ上で適宜ソースコードを弄る。
  5. Bさんは自分が修正した分をAさんに取り込んでもらいたくなったら、修正分をパッチでAさんに送る、またはAさんにBさんの公開リポジトリからpullしてもらう。

こういう流れにより、AさんはAさんで自分の好きなように開発を進めて、Bさんのように公開されているソースコードを見て気になった人は、自分の環境にソースコードを持ってきて自由に弄り倒して、本家に取り込んでもらいたい修正があれば、Aさんにお願いして取り込んでもらう事もできます。

それぞれがローカルリポジトリと公開リポジトリの両方を持っているのがミソで、ローカルリポジトリ上で好きなだけcommitしても他の人に一切影響を与えないので、開発をガンガン進めていく事ができるというのがポイントです。

Gitが元々Linuxの開発の為に作られたという事もありますが、分散型バージョン管理システムはオープンソースの開発に非常に適した作りになっていますよね。

進化していくソースコード

そして、本題。

分散型バージョン管理システムだと、ソースコードは次のような変遷を辿ります。

  1. どこかで誰かが新しく作り始める。(誕生)
  2. 気に入った他の誰かがforkしてソースコードを改変する。(突然変異)
  3. forkされたものの中で優れたものが生き残り、それ以外は淘汰される。(自然淘汰)*1

カッコ内に書いたように、それぞれの流れがちょうど生物の進化みたいだなと思うんですが、いかがなもんでしょうか?

こういった事が可能になる為には、

というような条件が必要になると思うんですが、GitHubが提供している場がまさにこれらを満たしている訳で、ソースコードが生物のごとく進化していく場としてGitHubは非常に可能性を秘めたサービスだと思います。*2

こんな思いもあって、Gitのこれからには非常に注目しております…が、まずは自分で使いこなせるようにならないといかんですな。(^^;ゞ

P.S.

Gitに関する書籍って無いのかなと思って調べてみたら、5月に洋書でOreilly本が出るようですな。

Version Control with Git

Version Control with Git

日本語版は多分出るのはまだまだ先になるんでしょうけど、割と期待度は高まっている(ような気がする)ので、その内に出るのかも?

*1:"淘汰される"というのはいい過ぎかもしれませんが、評価の高いもの程forkされ易いけど、評価されないものは多様化も進まないだろうな、という考え方です。

*2:そんな事を書きながら、自分はまだ全然GitHubを使っていないので、偉そうな事を言えるもんではないですが…。