コミットログから問題を閉じて変更できるだけでなく、問題を作成することも可能であることがわかったとき、SCM/バグトラッカーの統合を研究していました。
しかし、コミットログはコード変更用であるため、問題を作成するために誰かがコードを変更する理由がわかりません。これが正当化されるシナリオを1つ挙げてください。
コミットログから問題を閉じて変更できるだけでなく、問題を作成することも可能であることがわかったとき、SCM/バグトラッカーの統合を研究していました。
しかし、コミットログはコード変更用であるため、問題を作成するために誰かがコードを変更する理由がわかりません。これが正当化されるシナリオを1つ挙げてください。
1つのシナリオは、特定の問題の修正をコミットしているが、解決した問題が問題の短期的な修正であることを知っている場合です。
この場合、短期的な修正に照らして別の問題を開く必要があるかもしれません。そうすれば、将来のどこか で長期的な修正を提供する必要があることがわかります。
おそらく、バグレポートに複数の「サブバグ」が含まれている状況では、コミットによってそれらの「サブバグ」の1つを解決し、残りの「サブバグ」について別のレポートを作成できますか?
または、緊急のバグをすばやく解決するためにハッキーパッチをコミットする場合は、「ハッキーパッチを修正する」ための別のレポートを作成して、長期的な解決策を作成することをお勧めします。