同様の状況にあり、わからない場合 何が変わるか コードを壊した または WHO 多くの貢献者のうち 所有している この バグ/機能 、それならgitbisectがあなたの出口です。したがって、git bisectに関するこの記事では、「git bisect‘コマンドが来る バイナリ検索アルゴリズムを使用して、バグを引き起こす最初の不正なコミットを検出するのに役立ちます。
この記事で取り上げるトピックは次のとおりです。
なぜgitbisectを使用するのですか？
の小さな変更ごとに多数のコミットを作成する傾向があるという事実に疑いはありません。 。このようなシナリオでは、動作中のコードをテストしてバグを検出するために、プロジェクトスナップショットのすべてのリビジョンに手動で戻る必要があるため、コードのデバッグは面倒な作業になります。今、これはさらに多くなります 繁雑 リードポイントなしで検査する他の作業がある場合、各自に自分の間違いをクリーンアップするように要求することも、あまり現実的ではありません。
途中で、プロセスで多数の「機能」（またはホットフィックス）ブランチを作成して破棄し、開発のメインラインから逸脱する間に時間と労力を浪費することになる可能性もあります。
したがって、このようなシナリオを回避するには、git bisect不正なプロジェクトリビジョン（またはスナップショット）を見つけて、最終的にそれを修正するコマンドgit revertコマンド。
「gitbisect」はどのように検索しますか？
このコマンド 二等分 （分割）あなたの歴史を 良い そしてその 悪い コミット 範囲。 それはあなたを指しています 電流 事業 状態 に ミッドレンジ コミット スナップショット。次に、gitbisectコマンドが移動します すべてのコミットID この範囲の間 一時停止 各スナップショットで、 コードをテストする 。バグが存在する場合は、コミットを次のように宣言します 悪い、 そうでない場合 良い 検索が終了しない限り。
構文
git bisect
git bisectをよりよく理解するために、車で使用する簡単なナビゲーションアプリのコードを開発するプロジェクトを作成しましょう。
プロジェクトの初期設定
車で使用する簡単なナビゲーションアプリのコードを開発するプロジェクトを作成するには、次の手順に従います。
ステップ1： $ HOMEフォルダに新しいディレクトリを作成します。
cd $ HOME mkdir my_nav_app
ステップ2： 新しいディレクトリに移動します。
cd $ my_nav_app
ステップ3： クローンを作成して、GitHubページからプロジェクトをダウンロードします。
git clone https://github.com/divyabhushan/my_nav_app.git
ここで、コマンドによって出力されるプロジェクトディレクトリとファイルレイアウトを理解しましょう。ls -lTR
次に、このコードを生成するために行ったコミットを表示するために、プロジェクト履歴ジャーナルを見てみましょう-
たとえば、単純なgit logコマンドは履歴を詳細に出力しますが、私は履歴をきれいにフォーマットしてカスタマイズするのが好きです。それにより、 エイリアス名を設定する–「hist」 を使用して gitエイリアス 以下に示すコマンド：
git alias.hist'log --pretty = format： '％C（yellow）％h％Creset％ad | ％C（緑）％s％Creset％C（赤）％d％Creset％C（青）[％an] '-graph --decorate --date = short'
次に、「マスター」ブランチでのメインの開発に干渉しないように、このバグ修正機能を別のブランチで実行します。これを行うには、以下の一連のコマンドに従います。
- ブランチ「dev」を作成します。 [マスター] $
gitブランチ開発 - ブランチ「dev」に切り替えます。 $
git checkout dev - 履歴ログを一覧表示します。 [dev] $
歴史に行く[注：ここで使用される「エイリアス」コマンド]
さらに、スクリプトが期待されるテストケースの結果で正常に機能したことがわかっている最後の既知の良好なコミットを強調しました。このコミットスナップショットは次のとおりです。 タグ付き v1.0として。
最後の良いコミットがわかったので、「gitbisect」に関するこの記事に進んでアプリケーションをテストしましょう。
アプリケーションをテストする
スクリプトを次のように実行します– $./scripts/myApplication.sh[初めてのテスト]
明らかに、私の現在のプロジェクトの状態は エラー 、そしてこの変更を導入したコミットでどのような変更を加えたかはわかりません。それで、次にgit bisectに関するこの記事で、悪いコミットを特定する方法を見てみましょう。
悪いコミットの特定
不正なコミットの検査を開始するには、次の手順に従います。
- バイセクトコマンドを開始します ：
git bisect start - 不正なコミットIDに言及します。
git bisect bad HEADまたはgit bisect c5b3ca8 - last-known-good-commitidに言及します。
git bisect good v1.0またはgit bisect 93859d8
これは、コミットIDに到達する良いコミットと悪いコミットのほぼ中間のコミット履歴範囲を二分します。 f61a7e8
したがって、コマンドはこのコミットIDにあったプロジェクトバージョンをチェックアウトしました。それでは、先に進んでアプリケーションをもう一度テストしましょう。
アプリケーションを実行するコマンド ：$./scripts/myApplication.sh[2回目のテスト]
アプリケーション以来 合格しました このコミットでは、このコミットは確かに悪いコミットではありません。したがって、次に、bisectコマンドに次のように通知する必要があります– $git bisect good
これで、検索結果が次のように範囲の前半にさらに絞り込まれます–
アプリケーションを再度テストします–コマンド：$./scripts/myApplication.sh[3回目のテスト]
したがって、上記のようなエラーが表示されるため、これは不正なコミットです。
bisectコマンドに知らせ、$を実行しますgit bisect bad
これにより、検索がさらに絞り込まれ、最後の青い丸で囲まれた中間リビジョンに移動します。 a6ac769
したがって、同じコマンドを使用して、最後にもう一度アプリケーションをテストします。$./scripts/myApplication.sh[4回目のテスト]
さて、アプリケーションが再び失敗したので、それはまだ悪いコミットです。それでは、次のコマンドを実行してみましょう。
次のコマンドを実行します。 git bisect bad
不正なコミットが見つかりました
これで、最後に残った唯一の悪いコミットが終了します-
つまり、これがコードが壊れた場所であることがわかります。 次は何？
どのファイルにバグがあったかを理解する
この場合、出力はあなたに最小限の情報を提供します コミットID 、 著者名 、 そしてその 作成日 一緒に コミットメッセージ そしてその 道 それは変更されました。
さらにデバッグしたい場合は、 読んだ インクルード コミットIDオブジェクト 。
コマンド： git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
これにより、コミットオブジェクトが読み取られ、ログメッセージとテキストの差分が出力されます。
「gitblame」コマンドを使用して、各行がどの作成者によってどのように、どのコミットで変更されたかを分析し、次のようにコマンドを実行することもできます。git非難コード/develop_nav.sh
コンストラクターをプライベートにすることはできますか
検索を停止します
検索を停止するには、次のコマンドを使用します。
コマンド： gitbisectリセット
したがって、二分プロセスは停止し、検索を開始したブランチに戻ります。次のステップは、コードを修正またはデバッグすることです。
コードを修正/デバッグする方法は？
さて、最初にバグを引き起こしたコミットを特定したので、プロジェクトの現在の状態を修正するために実行できるいくつかの回避策があります。
ただし、コミットを変更する場合 共有リポジトリ それが最善です 元に戻す ‘を使用した変更 git revert ‘コマンド。
仕事： 上記の不正なコミットによって行われた変更を元に戻します
コマンド： git revert a6ac769
その結果、このコミットによって行われた変更を元に戻すと、次の2つのことが行われました。
- 追加された最後の3行（緑で表示）を削除し、削除された行（赤で表示）を追加し直しました。 （a6ac769の逆）
- 元に戻すメッセージ情報を使用して追加のコミットを作成しました
「元に戻すコマンドを使用すると、元のコミットから元に戻した変更を簡単に追跡できます」
使用 '公演' 次のように、オブジェクトIDを読み取るようにもう一度コマンドします-
コマンド： git show 801f029
次に、アプリケーションをテストします。正しく実行されます。
コマンド： $./scripts/myApplication.sh
対照的に、履歴から不正なコミットを削除したい場合：
‘を使用できます
gitリセット‘コマンドと“- ハード」オプション（共有リポジトリでは推奨されません）。‘を使用して単一ファイルの以前のバージョンを確認してください
git checkout‘コマンドと‘-‘オプション。
これは、変更をリモートリポジトリにプッシュするまで、ローカルリポジトリにのみ変更を加えることに注意してください。上記の場合のように、一部の変更により新しいコミットオブジェクトIDが作成されるため、このような場合、履歴が分岐するため、リモートリポジトリへの通常のプッシュは拒否されます。 ‘を使用する必要があります git push ‘コマンドと‘ - 力‘オプション。
「マスター」ブランチを更新します
「dev」ブランチのバグを修正しましたが、この変更を「master」ブランチとマージできるようになりました-
- 「マスター」に切り替え、コマンド：
gitチェックアウトマスター - 最近の更新を「origin / master」から「master」にプルします。コマンド：
git pull origin - 「dev」の変更をマージ、コマンド：
gitマージジャイアント
ただし、リモートリポジトリからのコミットがさらにある場合、マージによって競合が発生する可能性があります。競合を解決し、マージを続行します。
最後に、安定した「マスター」ブランチのコミットのみをリモートリポジトリにプッシュし、この例では「dev」などの機能ブランチでのみダーティな作業（バグ、機能、拡張機能）を実行します。
さらに、論理を採用するのが最善です 分岐戦略 gitワークフロープロセスを合理化して保護します。
要約すると、「gitbisect」は便利で便利なコマンドです。 識別する インクルード コミットID それ 導入 に 障害 広範な助けを借りてあなたの実行中のコードで 二分探索 論理的に 分割 コミットログは 良い そして 悪い コミット 範囲 。結論として、あなたは 検出する 誤ったコミットと 元に戻す それによって行われた変更。
さらに、サブコマンド「good」と「bad」に、newやoldなどの用語を使用してリビジョンの状態を説明することもできます。 異なるサブコマンドとリビジョン/コミットIDを渡してコマンドを複数回実行し、異なるコミット（she-1）IDを識別することができます。または、自動テストスクリプトを実行して、このコマンドを使用して壊れたコードを作成することもできます。また、を実行してこのコマンドの詳細な説明を見つけますgit bisect --helpターミナルで。これで、GitBisectに関するこの記事は終わりです。
DevOpsの目的は、チーム間のコミュニケーションとコラボレーションを促進しながら、より高品質のソフトウェアをより迅速かつ信頼性の高い方法で作成することです。この記事に興味がある場合は、c 一体 25万人以上の満足した学習者のネットワークを持つ信頼できるオンライン学習会社であるEdurekaが世界中に広がっています。 Edureka DevOps認定トレーニングコースは、学習者がDevOpsとは何かを理解し、SDLCの複数のステップを自動化するためのPuppet、Jenkins、Nagios、Ansible、Chef、Saltstack、GITなどのさまざまなDevOpsプロセスとツールに関する専門知識を習得するのに役立ちます。
質問がありますか？ 「GitBisect」の記事のコメントセクションにその旨を記載してください。できるだけ早くご連絡いたします。