コードベースの別の部分で作業中にバグを修正する

これは少なくとも一度は私に起こりました。私はコードベースのある部分に取り組んでおり、別の部分に小さなバグを見つけました。そのバグは、私が現在やろうとしていることを完了するのを妨げます。バグの修正は、単一のステートメントを変更するのと同じくらい簡単です。

その状況で何をしますか？

1. バグを修正し、現在の作業と一緒にコミットします
2. 現在の作業を別の場所に保存し、別のコミットでバグを修正してから作業を続行してください[1]
3. あなたがすることになっていることを続けて、コードをコミットします（たとえそれが ビルドを壊します いくつかのテストに失敗します）、バグを修正します（そして ビルド 別のコミットでテストに合格する）

[1]実際には、これは、元のリポジトリを他の場所に複製し、バグを修正し、変更をコミット/プッシュし、作業中のリポジトリにコミットをプルし、変更をマージし、作業を続行することを意味します。

編集：私は本当に意味を反映するために3番を変更しました。

私は1と2をやったので、最終的には私は＃2を好むと思います。バグ修正の可視性を高めることができます。これは、QA /リリースノート/その他の開発者にとって重要な場合があります。

私はバグだと思っていたものが実際にはそうではないという状況に遭遇しました（ここではそうではありません）、別のコミットでそれを「修正」すると、別の開発者が私に連絡して通常のチェックインで失われる「修正」の代わりに。

私は通常＃2に行きます。これにより、リポジトリがクリーンになり、ログがより理解しやすくなります。私がコミットしている他の開発者が15の異なるバグ修正、機能、リファクタリングをすべて同じコミットで行っているとき、私はそれを嫌います。

また、チームが欠陥追跡をどのように行うかに応じて、欠陥レポジトリを検索して、修正する欠陥がそこにある場合、アイテムに完了のマークを付ける必要があります。または、欠陥システムとコードリポジトリが一致するように、新しいアイテムを作成して完了としてマークする必要がある場合があります。

＃2を行います。gitなどのツールを使用すると、複数のコミットに分割するのが簡単になります。チームに最新のツールに切り替えるよう説得できない場合、git-svnはこの問題を解決するために使用するものの適切な部分を提供します。このブログ投稿では、解決しようとしているワークフローの概要を説明しています：The Thing About Git

未記述のオプション（4）を選択します：プロジェクトを高度に専門化されたアセンブリ/ライブラリに分割し、無関係なバグが常にバージョン管理ツリーの別の場所にあるようにします。

上記の音がひどい場合はおaび申し上げますが、誠意を表します。互いに関係のない100のフォームと名前空間を持つモノリシックなプロジェクトを見るたびに、私はうんざりします。私はこれと同じジレンマにしばしば直面し、異なる機能領域を扱っていたコミットを分割すべきかどうか、またどのように分割すべきかを考えていました。単一のコミット可能なプロジェクトにこれらの異なる機能領域をすべて持つことが、それ自体が主要な設計上の欠陥であることに気づいたのはずっと後のことでした。

特定の機能に取り組んでいる間も、まったく関係のないバグを頻繁に見つけます。UIで作業していて、いくつかのビジネスロジックのバグを見つけたので、先に進む前に修正する必要があります。違いは、ビジネスロジックが常に UIとは異なるアセンブリ/プロジェクトにあるため、BLに1つの非常に小さな変更を加え、1つの非常に小さなコミットを行ってから作業を続けることだけです。

非常に優れたプロジェクト組織があれば、変更を埋めたり、ビルドを壊したり、刺激的なブランチ/マージに夢中になったりすることなく、これらの問題を簡単に処理できます（DVCSを使用している場合でも、まったく痛みはありません））。

このオプションがない場合、つまり、プロジェクト組織で発言権のないジュニア開発者の場合、＃1に進み、ログに適切なメモを作成して、他の人があなたが何をしたのかを知るようにします。大きな変更を行った場合は、問題追跡システムにバグレポートを提出して、修正内容とその理由を把握できるようにします。

＃2を試みます。本当に別の問題である場合は、作業中のものとは異なるファイルにある可能性があります。作業中の同じリポジトリで作成された場合でも、ファイルを個別のコミットとしてチェックインできる必要があります。すでに述べたすべての理由から、変更を追跡し、間違っている場合は変更を元に戻すために、可能な限り独立したコミットを行うのが理にかなっています。

通常はバグを修正してから、作業を続けます。バグ修正が別のファイルにあると仮定してコミットするとき、私は2つの同時コミットを行います-最初はバグ修正のみを含む部分的なコミットであり、2番目は他のすべてです。

短い答え：＃2。あなたは本当にそのバグ修正（あなたのトラッカーでのメモ付き！）をあなたのバージョン履歴で別のエンティティとしてタグ付けしたいです。

より長い答え：

• バグに出くわす
• バグを実証するテストなどを書く
• テストに合格する
• その変更とそのテストのみをコミットします（git add --interactiveまたはdarcs record -iVCSがそれを実行します）（*）
• 私がやっていたことに戻ってください。

（*）CVSでは（いや、本当に）私は時々きれいなツリーをチェックアウトし、自分が作業しているコピーを持っています。次に、マージ-私の場合はwinmergeを使用して、バグ修正だけをクリーンなツリーに取り込み、個別にコミットできるようにします。（他のオプションは、変更したファイルの名前を変更cvs updateしてマージします。変更をコミットしたら、ファイルを削除し、移動したファイルの名前を元の名前に戻します。）

ただし、注意しなければならないのは、通常、自分が作業しているものに関連するバグ、または語彙的に近いバグのみを見つけることです。人々がコードベースの無関係な部分でバグを見つけるのが普通だったら驚きます-バグを修正するときに無関係のコードを読むのはなぜですか？（はい、これはAaronnaughtが言うことの正反対です！）

バグを修正し、修正/機能ごとに個別のコミットを行います。

ほとんどの場合、変更は同じファイル内にないため、コミットを簡単に分離できます。変更が同じファイルにある場合、TortoiseHg（mecurial GUIフロントエンド）を使用して、コミットするdiffを正確に選択します（Record拡張機能を使用してコマンドラインでこれを行うことは可能だと思いますが、あまり便利ではありません） ）。

一部の人々はMercurial Queuesを使用して、機能の作業中にマイナーな修正を分離します。マイナー修正はMQに積み重ねられ、機能が終了してコミットされると、キューの内容もコミットされます（キュー内の各エントリに対して1つの変更セット）。

私は通常＃2を行います。現在の作業を別の場所に保存する：これは通常、パッチを作成することで正常に機能します。また、一部のIDE（IntelliJ）では、現在の作業を別の場所に保存するという、まさに変更を保留することができます。

私がすることは、バグが本当に別の部分にあるかどうかに依存します。そうである場合、チェックインは、私の半分行われた変更とは無関係です。変更を加え、その別の部分をビルドして、些細なエラーが発生していないことを確認し、テストして（おそらく、実行できないようにしていることを実行することによって）、何が起こっているのかを説明して確認します。多くの場合、作業項目を作成し、チェックイン/解決後、WIをテスターに​​割り当てます。それから、私がやっていたことに戻ります。

すべてが半分変更されたファイルでいっぱいになっている場合、その部分を個別にビルドおよびテストすることはできません。その場合、私は別のWIを作成し、変更をチェックインするときに、同じチェックインで両方のWIを解決します。これは通常私の原則に反しますが、この場合はうまく適用されます。

両方の状況で、バグ修正は私によってテストされ、何らかの種類の証跡でチェックインされるため、その日にコードをランダムに変更した理由を人々が理解し、WIが現在正しいことを確認するために他の誰かに割り当てられます。

＃1を行います。＃2は良さそうに聞こえますが、＃1で＃2が修正する問題があったとは言えません。

私の会社のもう1つの要因は、Webアプリを構築することです。テストはほぼ完全にWebインターフェイスを介して行われます。大まかに言うと、ユニットテストではなく機能テストと呼ばれます。チェックインする前にすべてのテストに合格します。コミットを小さなビットに分割すると、各ビットごとにテストを1回実行することになり、時間がかかります。より小さなコミットを実行できるように、はるかに高速なテストスイートを作成したいのですが、まだありません。