コミットメッセージ内のバグ/問題への言及は良い習慣と見なされていますか？

バグトラッカーにメモを自動的に書き込むようにソース管理を設定しているプロジェクトに取り組んでいます。コミットメッセージにバグの問題IDを書き込むだけで、コミットメッセージがバグトラッカーへのメモとして追加されます。

このプラクティスの欠点はほんの少ししかありません。将来、ソースコードがバグ追跡ソフトウェアから分離された場合（または報告されたバグ/問題が何らかの形で失われた場合）。または、誰かがコミットの履歴を調べているが、バグトラッカーにアクセスできない場合。

私の質問は、コミットメッセージにバグ/問題の参照を含めることをお勧めしますか？他にも欠点はありますか？

私たちはこのプラクティスを採用しており、非常にうまく機能しています。バージョン管理システム（VCS）と私たちが使用している他のシステム、例えば継続的インテグレーション、バグトラッカーなどの間の緊密な統合は非常に貴重です。将来何かを変更する場合、VCSとバグ追跡システム間のリンクを含む副作用を評価する必要があります。

一般的に、これは良い習慣だと思います。一部の追跡システムでは、Subversion（SVN）のbugtraqプロパティなど、追加のオプションとツールを使用できます。これは、かなりの数の人々がこの実践に価値を見出していることを示唆しています。

本当に別のバグトラッカーを使用したり、バグトラッカーのデータが何らかの形で消えたりしても、情報が失われないことを本当に確認したい場合は、問題ID とバグに関する簡単な説明の両方を入れてくださいコミットメッセージ？

バグ＃123を修正：ログイン後にアプリがクラッシュする

コミットの履歴からバグトラッカーへのリンクがまだあります。バグトラッカーを使用できなくても、この特定のバグが何であるかを履歴で確認できます。

これは非常に一般的な方法であり、非常に便利であることがわかりました。TRACを使用しているため、コード履歴を読み取って変更を引き起こしたタスクに移動したり、タスク履歴を読み取ってコード変更に移動したりできます。

「将来いつか...」バグトラッカーからコードを分離する場合、おそらく古いリビジョン履歴はそれ以上興味がないでしょう。

私もこの方法を使用し、非常に良い方法だと考えています。ただし、問題IDに加えて、バグ/機能の簡単な説明（通常はバグ追跡システムのタイトル）を追加します。バグ追跡システムを検索する必要がないため（変更を認識するため）、時間の節約に役立ちます。また、あなたが言ったように、何らかの理由でバグ追跡システムを失っても完全に失われることはありません。