コミットコメントの書き方(続き) - 地平線に行く
先日のコミットコメントの書き方(我流)に対して、twitter でコメントをいただきました。 BTS連携があればチケット番号も [subversion]いいね！ 僕はBTSと連携させることが多いので、太括弧【】の部分がチケット番号 #XX になりまする。連携できないときはこうしてみようかな / コミットコメントの書き方(我流) - 地平線に行く http://twitter.com/kaorun55/status/7460414770118657 確かにチケット番号あった方がいいですね・・・。 それに、コミットコメント欄に書くよりもBTSに詳細を書く方が、読みやすそうです。 （コメント欄は Wiki フォーマットが使えないので、あまり長く書くとメリハリがつかなくて読みにくいという問題があります） BTS自体は使っている(Trac)ので、連携設定をいじってみたいと思います。 修正しない点があ
コミットコメントの書き方(我流) - 地平線に行く
Subversionのコミットコメントは、人によって多々書き方が違います。 ただ、後でコミットの内容を確認した時に 何も書かれていなかった 書いてあっても一行だけだった となっていて、詳細が分からず、本人に聞いたりドキュメントを探して確認する羽目になったことが何回もあります。 そうした経験から、コミットコメントを書く際には、あとで自分が困らないように、ほかの人が困らないように以下のようなポイントに気をつけて書いています。 一行目には、変更種別を書く 一行目には、必ず変更の種別を書くようにしています。 たとえば、 機能追加 仕様変更 不具合修正 リファクタリング などです。 また、仕事の時はそれと一緒に件名も書いて、太括弧【】に囲んで記述しています。 （例：【不具合修正：ログイン画面】） こうすると、変更理由をヒストリー一覧から探しやすくなります。 また、あとで見返したときに「このリビジョン
チケットの書き方（我流） - 地平線に行く
自分が今いるチームは、3か月半ぐらい前にTracを導入して、チケット駆動開発に移行しました。 今では、チケットを中心に作業を進め、進捗の報告もチケット上で行っています。 そんなチケットですが、より作業がスムーズに進むよう3タイプの人を意識して書くように工夫しています。 同僚、先輩 → 詳細に書く 同僚や先輩に向けてチケットを書くときには、できるだけ詳細に書くように注意しています*1。 バグ報告のチケットなら、 発生手順（どういう前提条件で、どう操作をすれば発生するのか） 根本原因（ただの単純ミスなのか、設計上の問題なのか） 修正方法（どのクラスを直すか、水平展開のポイントはどこか） といった点を詳細に書いています。 Trac導入前だと、これらを口頭で説明したり、手書きのメモで箇条書きにして渡したりしていました。 でも、これだと相手に意志がうまく伝わらず、直したと言われてもチェックしたら直っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
