gitbisectを使用してバグを発見する方法

Gitを使用して追跡され、変更の長い履歴を含むほとんどすべての問題をデバッグし、コードにバグが発生した時期を発見する方法

時々私達は長い間プロジェクトに取り組んでいます。完璧な1.0リリースを作成し、それを一般にリリースしてバグ修正に取り組み始め、機能リクエストを受け取り、アプリの改善に取り組んでいます。

このプロセス中のある時点で、回帰バグ：コードの無関係な変更によって引き起こされる予期しない問題。

最近コードのその部分を実際に変更していませんが、何かが期待どおりに機能していません。

または、ファイルや関数に何度も触れたために、報告された問題の原因となった可能性のある変更を思い出せない場合もあります。

いずれにせよ、最初にすべきことはバグがどこにあるかを特定する。

次のようなバージョン管理システムを使用して作業している場合ギット、物事は簡単です。時間をさかのぼって、変更を導入した正確なコミットを把握できます。チームで作業する場合、他の人がそれに取り組んでいる可能性があるため、これは重要です。エラーが発生した場合は、Gitがこの情報を提供するため、修正を依頼する以外はどうすればよいかわからない場合があります。

これを行う1つの方法は、特定のコミットを手動でチェックアウトすることです。たとえば、昨日のバージョンのコードベースが正常に機能したかどうかを確認することから始めることができます。

私が使うGitHubデスクトップ、素晴らしいGitクライアントGitHub。日常の使用には最適ですが、1つのコミットをチェックアウトすることはできません。他のいくつかのクライアントはそうしますが、あなたはコマンドライン。

実行

git checkout <COMMIT_SHA>

どこロールバックするコミットです。それは次のようになります5a06d3ca5e7adb6e67。

それでも問題が解決しない場合は、コードが機能するコミットが見つかるまで、前日から別のコミットで同じことを試してみてください。

今、あなたは適用する必要があります分割統治原則として、最後に試した（そして機能しなかった）コミットと機能するコミットの途中でコミットを選択します。

問題の原因となったコミットを特定するまで、プロセスを繰り返し、コミットの間隔ごとに半分にカットします。

これは、Gitが導入した非常に一般的で便利なことです。bisectこのプロセスを自動化するコマンド。

最新のコミットから開始します。使用するgit checkout your-branch-name、 例えばgit checkout master古いコミットをすでにチェックアウトしている場合。

次に、以下を実行します。

git bisect start

まだ何も起こりませんでした。あなたはGitに伝える必要があります悪いコードが機能しないコミット参照：

git bisect bad HEAD

と良いコードが機能した場所でのコミット：

git bisect good 7f4d976e7540e28c6b0

Gitはプロセスを開始します：

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

ほら、HEADと私が良いと言ったコミットの間に6つのコミットがあります。 Gitは、問題のあるコミットが見つかるまで、あと2つのステップがあると言っています。

コードをテストしてから、Gitに結果を伝えます。git bisect badまたはgit bisect good成功に応じて。

不正なコミットが見つかるまで繰り返してから、実行しますgit bisect resetHEADコミットに戻ります。

Gitは、この二等分線の操作をガイドします。コミットのSHAを入力します


その他のgitチュートリアル：


Tech Wiki Online！