Tracのタイムラインを見やすくする - 地平線に行く
自分が使っているTracでは、更新もタイムラインに表示するように設定しています*1。 これで、更新がすぐにわかって便利！と思ったんですが、更新頻度が高いと肝心の登録/解決が埋もれる・・・。 そこで、見やすく色分けしてみました。 div.timeline dl dt.newticket a{ background-color: lightpink; } div.timeline dl dt.closedticket a{ background-color: lightpink; } div.timeline dl dt.editedticket a{ background-color: wheat; } これで、見逃さずに済みそうです。 *1:こちらのサイトを参考にさせていただきました。Trac ： コメントや属性の変更などチケットに加わった変化を追跡する方法｜A Day In The Bo
コミットコメントの書き方(続き) - 地平線に行く
先日のコミットコメントの書き方(我流)に対して、twitter でコメントをいただきました。 BTS連携があればチケット番号も [subversion]いいね！ 僕はBTSと連携させることが多いので、太括弧【】の部分がチケット番号 #XX になりまする。連携できないときはこうしてみようかな / コミットコメントの書き方(我流) - 地平線に行く http://twitter.com/kaorun55/status/7460414770118657 確かにチケット番号あった方がいいですね・・・。 それに、コミットコメント欄に書くよりもBTSに詳細を書く方が、読みやすそうです。 （コメント欄は Wiki フォーマットが使えないので、あまり長く書くとメリハリがつかなくて読みにくいという問題があります） BTS自体は使っている(Trac)ので、連携設定をいじってみたいと思います。 修正しない点があ
コミットコメントの書き方(我流) - 地平線に行く
Subversionのコミットコメントは、人によって多々書き方が違います。 ただ、後でコミットの内容を確認した時に 何も書かれていなかった 書いてあっても一行だけだった となっていて、詳細が分からず、本人に聞いたりドキュメントを探して確認する羽目になったことが何回もあります。 そうした経験から、コミットコメントを書く際には、あとで自分が困らないように、ほかの人が困らないように以下のようなポイントに気をつけて書いています。 一行目には、変更種別を書く 一行目には、必ず変更の種別を書くようにしています。 たとえば、 機能追加 仕様変更 不具合修正 リファクタリング などです。 また、仕事の時はそれと一緒に件名も書いて、太括弧【】に囲んで記述しています。 （例：【不具合修正：ログイン画面】） こうすると、変更理由をヒストリー一覧から探しやすくなります。 また、あとで見返したときに「このリビジョン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
