コミットルール - Tera Term Wiki - Tera Term

コミットルールについて

コンポーネントのバージョン

• Tera Term, TTSSH, TTProxyなどのバージョン情報を上げてコミットしないこと。リリース物件の作成者のみが上げることができる。
• バージョン情報を上げるタイミングは RC版 とする。

言語ファイル(.lng)

• lng ファイルを更新した場合は、1行目の「Updated by TeraTerm Project」の日付を更新する。
• 1行目の「TeraTerm Project 最終更新日」より 2行目の「最終翻訳日」が古い場合は「未翻訳部分がある」、つまり言語ファイルのメンテナンスが必要であることを表せるようになっています。

コミット禁止(コードフリーズ)期間

• リリース予定日の週にRC版が提供されるため、リリース予定日から約一週間前をコードフリーズとし、大きな修正は入れないものとする。
• コードフリーズ期間中はバグ修正のみ行う。
• ドキュメントに関してはリリース直前まで修正可能。

ビルド確認

ソースコードをコミットする前にVisual Studio 2005(Standard Edition以上)でビルドが通ることを確認する。
Tera Termのリリースビルドに使うのはVisual Studio 2005だからである。

※Tera Term 4.103からはVisual Studio 2005 Express Editionでもビルド可能となった。
※Visual Studio 2005がない場合は別途相談のこと。

リポジトリの使い分け

リリースビルド対象はtrunkであるため、バックアップ目的で使わないこと。
大きな修正を入れたい場合はブランチ(branches)を作ることを推奨する。

コードレビュー

ソースコードのコードレビュー(クロスレビュー・クロスチェック)は行わない。
trunk にコミットしたコードがかならずチェックされるわけではないため、
コードレビューが必要な場合は、別途依頼を出すこと。

コミットの単位

• ひとつのコミットでひとつのバグ修正を行うこと。
• ひとつのコミットでひとつの機能追加を行うこと。
• ひとつのコミットでひとつの機能改善を行うこと。

すなわち、ひとつのコミットでひとつの単位とする。

こうすることで、後で問題が発生した時に、切り分けがしやすくなる、 特定のコミットのみをリポジトリから取り消ししやすくなる、という メリットが生まれる。

コミットメッセージ

(1)コミットメッセージは修正した内容が簡潔に分かるように書く。

• 事例(1)

よくない例

プロジェクトファイルを修正した。

よい例

VS2005でビルドが通らない問題を修正した。
XXXヘッダファイルの指定ミス。

• 事例(2)

よくない例

TTSSHが落ちる問題を修正した。

よい例

SSH2接続でXXXした時にTTSSHが落ちる問題を修正した。

(2)チケットに関連するコミットはチケット番号を記載する
コミットメッセージにチケットへのリンクが自動的に張られるからである。

XXXという問題を修正した。
チケット#12345