チケット番号を含むメッセージをコミットするための欠点はありますか
コミットメッセージに別のチケット番号を含めるのは良い習慣になるのではないかと思っていました。それは
2568 Fix heating issue
Summary of the issue with a bunch of detailed comments
コミットごとにチケットまたは問題を取得するのは少し面倒です。長期的には価値があると人々が考えているのではないかと思います。また、私のブランチにチケット番号がある場合、これは冗長ですか？主な問題は、ソースツリーを使用していることと、ログ/履歴ビューで、どのコミットがどのチケットに対応しているかを確認するのが少し複雑になる可能性があることです。すべてがどのように機能するかを確認するより良い方法が欲しいだけです。
はい、これは良いアイデアであり、かなり標準的な（しかし普遍的ではない）慣行です。
これで達成している具体的なソフトウェアエンジニアリングの目標は 要件トレーサビリティ です。アイデアは、ソフトウェアプロセス全体を通じて要件を追跡できるようにすることです。
- ビジネス要件
- 機能要件
- 技術要件
- コードアーティファクト
- QAフィードバック
- 開発の修正
コミットメッセージおよび任意の通信でチケットまたは要件番号（例：JiraストーリーID）を使用することにより、そのソフトウェアエンジニアリングの目標に向けて取り組んでいます。
1年後に戻ってきてコミットメッセージが表示された場合は、別のシステムでその数を調べて、afterコミット。
システムがすべての機能/バグを追跡している場合、おそらく何らかのチケットが必要になります。しかし、システムが（何らかの理由で）バグを追跡するだけで、すべての新しい開発はすべて無料です。
いくつかの重要な利点：
- 一部のVCS /チケットシステムでは、課題追跡でコミットを参照するときに、チケット番号の自動ハイパーリンクを使用できます（これは非常に便利です。 github 、 redmine を参照してください）
- それは、不可避の「なぜSimonがこれをしたのですか？意味がありません！」質問
- 多くの場合、これは数年後かもしれません...
- 変更のコンテキストは、今後数年で多くの作業が必要になる可能性があります。 whyの説明が付いたチケットがあると、コードが変更され、非常に便利になります。
- 人々が付加価値のあるものに取り組み続けるのを助けます
- 「ああ、私はこれをリファクタリングするつもりです...これとこれとこれ...そして...私は一週間で付加価値のある仕事をしていません！」
- 問題に関連するコミットを検索で検索できるようにすることができます
唯一の欠点は、チームが実際にチケットや追跡システムを使用していない場合です。そうすると、チケット番号を見つけるのが難しくなります。または、VCSと課題トラッカーがうまく統合されていない場合。
そして...すべての努力をどこかに追跡する必要があるので、それがあなたの仕事のほとんどすべてにチケットシステムを使用していない理由である場合、コミットメッセージに含まれているかどうかにかかわらず、そうすることを強くお勧めします。
欠点は、誰かがチケットにアクセスして詳細を確認できるため、完全なコミットコメントが少なくなることです。これが本当に問題になるのは、別の発券システムに切り替えて履歴を保持できない場合、または誰かが発券システムを持っていないがリポジトリにアクセスできる場合だけです。
ブランチがすでにチケット用に名前が付けられている場合、私はそれをコミットに入れたくありませんが、それは冗長に思えます。
コミットメッセージに参照番号（チケット、機能、要件、etc。）を含めることは素晴らしいアイデアです。しかし、それは良いメッセージの代わりになることはありません。現在の雇用主では、2番目のソース管理システム、3番目の発券システム、2番目の要件管理システムを使用しています。言うまでもありませんが、古いシステムのデータが代替に移行されることはなく、たとえそうであっても、番号付けシステムは重複しています。