発見してパッチを当てたバグを記録する必要がありますか？
これは一般的な状況だと思います。コードをテストし、バグを発見して修正し、バグ修正をリポジトリにコミットします。多くの人がこのプロジェクトに取り組んでいると想定して、まずバグレポートを作成して自分に割り当て、コミットメッセージでそれを参照する必要があります（たとえば、「バグ#XYZを修正してください。バグはXとYが原因でした。 QとR "）？または、バグレポートをスキップして、「BのときにAを引き起こしたバグを修正しました。バグはXとYが原因でした。QとRで修正しました」などのメッセージでコミットできます。
何がより良い実践と考えられますか？
バグレポートの対象者が誰であるかによります。
修正が必要なものを知るために、開発者が内部的にのみ見ている場合は、気にしないでください。その時点では単なるノイズです。
とにかく記録する理由の網羅的ではないリスト：
- リリースノートには、修正されたバグ（このバグが満たすしきい値まで）に関する情報が含まれます-特にこのバグによって公開された脆弱性がある場合
- 経営陣は、「バグ修正に費やした時間」/「検出されたバグ数」などの概念を求めています。
- 顧客はバグトラッカーの現在の状態を確認できます（問題が既知であるかどうかを確認するためなど）。
- テスターは、テストする必要がある変更に関する情報を取得します。
私が言うには、それはあなたの製品がバグでリリースされたかどうかに依存します。
発見したバグがリリースされている場合は、はい、バグレポートを作成してください。多くの場合、リリースサイクルは長くなる可能性があり、すでに修正されているバグを新しい問題として報告したくない場合があります。
バグがまだ出荷されていない場合、私は同じ道をたどらないでしょう。これで、まだリリースに含まれていないためにできなかったバグを再現しようとする人々がいることになり、本質的に時間を浪費しています。
顧客から報告された可能性があるバグの場合は、これを行う必要があります。最悪の場合：あなたはバグを修正しますが、誰も知りません。顧客がバグを報告します。同僚はバグを修正しようとしますが、それを再現することはできません（すでに修正しているため）。そのため、バグの記録が必要です。
コードレビューを行う場合にも役立ちます。通常、コードはいくつかのタスク用に記述され、レビューされます。その場合は、そのバグ修正を分離しておくとよいでしょう。タスクリストに何かを入力してから、すべての作業を行う必要がある場合があります。
これはいくつかの要因に依存します。
ピーターBとカレスの両方が回答にいくつか挙げています。
- バグは公式リリースの一部ですか？
- それらに費やされたバグ/時間の数は具体的に追跡されていますか？
多くの場合、認証の要件に裏付けられた、従うべき内部手順も存在します。特定の証明書については、コードのすべての変更が課題追跡のレコードに追跡可能であることが必須です。
さらに、たまに見えるバグ修正でさえ、最初に現れるほど簡単で無害ではない場合があります。このようなバグ修正を無関係な問題の配信に黙ってバンドルし、後でバグ修正に問題があることが判明した場合、これは追跡または特定すること、あるいは元に戻すことをはるかに困難にします。
この質問に答えられるのは、プロジェクトリーダー、または「チケット発行プロセス」の担当者だけです。
しかし、別の方法で質問させてください。なぜあなたはパッチを当てたバグを記録するのですかnot？
私が知る唯一の明らかな理由は、バグレポートを提出し、それをコミットし、それを閉じるための労力が、バグを修正する時間よりも桁違いに大きいということです。
この場合、問題は、バグが簡単に修正できることではなく、事務処理に時間がかかりすぎることです。それは本当にすべきではありません。私にとって、Jiraチケットを作成するためのオーバーヘッドはcを押してから、短い1行の要約を入力し、Enterを押すことです。私はそれを問題番号と一緒にコミットメッセージにカット＆ペーストできるので、説明はオーバーヘッドすらありません。最後に、 . c <Enter>で問題は解決しました。つまり、オーバーヘッドの5つのキーを押すことになります。
私はあなたのことは知りませんが、小さなプロジェクトでさえ、この方法でeveryバグ修正を記録することをポリシーにするのに十分ではありません。
利点は明白です。ソースコードではなく、Jiraのようなチケットシステムを簡単に操作できる人がかなりいます。ソースからではなく、チケットシステムから生成されたレポートもあります。あなたは間違いなくそこにあなたのバグ修正を望みます、小さな1行のバグ修正の着実に増加する流入のような可能性のある開発について学ぶために、それはあなたにプロセスの問題や何かへの洞察を提供することができます。たとえば、why（頻繁に発生すると仮定して）このような小さなバグ修正を頻繁に行う必要がありますか？あなたのテストは十分ではないかもしれませんか？バグ修正はドメインの変更ですか、それともコードエラーですか？等。
私が従うルールは、作業しているセクションがリリースされたことがなく、まだ実行されておらず、誰もそれを見たことがない場合は、すぐに見えるすべての小さなバグを修正して次に進むことです。ソフトウェアがリリースされて本稼働状態になり、一部のユーザーがそれを見た場合、目にするすべてのバグはバグレポートを受け取り、レビューされます。
私がバグだと思うのは、他の誰かのための機能であることがわかりました。これらのバグをレビューせずにバグを修正することで、修正するのではなくバグを作成する可能性があります。バグレポートに、バグを修正するために変更する行と、修正方法に関する計画を入力します。
まとめ：このモジュールが本番稼働されたことがない場合は、すぐにわかるすべてのバグを修正し、仕様に従ってください。モジュールがすでに本番稼働中の場合は、修正する前に確認するバグレポートとしてすべてのバグを報告してください。 =
はい。
バグレポートを作成する価値がある状況を明らかにするいくつかの回答がすでにあります。 いくつかが答えます。そして、彼らは異なります。
唯一の答えは、誰も知らないということです。異なる人々異なる時間は、この問題について異なる意見を持っています。
したがって、バグに遭遇した場合、2つの解決策があります。
- バグレポートを開く価値があるかどうかを熟考し、同僚の意見を聞くかもしれません...その後、場合によっては、誰かがそれについて質問しているのでそうしなかったことを後悔しますちょうどそれらを指す
- レポートを作成するだけ
レポートの作成はより速く、そうでなければ...自動化します。
自動化する方法は？トラッカーがスクリプトをサポートしていることを前提として、呼び出し可能なスクリプトを作成するだけで、コミットメッセージ（タイトルと本文）を使用してバグレポートを送信し、すぐに「実装済み」として閉じます。
他の答えはすべて良い経験則を提供し、いくつかはこの点について触れさえすることに同意するつもりですが、私はここに本当に確かな答えしかないと思います。
マネージャーに聞いてください。まああなたのマネージャー、または代わりにあなたのグループがどのように構成されているかに応じてプロジェクトリーダーまたはスクラムマスターなど。
良い実践と悪い実践にはさまざまなシステムがありますが、チームにとって正しいことをしていることを知る唯一の方法は、質問することです。
「ちょっと（上司）、ほんの数分しかかからないマイナーなバグを修正した場合、チケットを作成する価値があるか、またはすべきでしょう。私は自分のコミットメッセージでそれについて言及しているだけですか？」そしてあなたは確かに知っているでしょう。その方法があなたのチームとあなたのマネージャーを悩ませるならば、世界のすべての良い習慣は役に立たないです。