2021年のトップ40のGITインタビューの質問と回答

top 40 git interview questions

回答と例を含む最も人気のあるGITインタビューの質問：

この有益なチュートリアルには、Gitインタビューで最もよくある質問のセットとその説明的な回答が含まれています。これらの質問は、Gitインタビューの準備とクラックを成功させるのに役立ちます。

あなたが初心者であろうと経験豊富な専門家であろうと、Gitに関するこれらの面接の質問と詳細な回答は、あなたが主題についての知識を豊かにし、面接だけでなくあなたの仕事で優れているのに間違いなく役立ちます。

始めましょう！！

最もよくあるGITインタビューの質問

以下に、参考のためによくあるGIT面接の質問の一部を示します。

Q＃1）Gitとは何ですか？

回答： Gitは分散バージョン管理ツールです。高品質のソフトウェアを構築するためのデータ保証を提供するため、分散型非線形ワークフローと互換性があります。

Gitは無料でオープンソースです。サイズが小さいか大きいかにかかわらず、ほぼすべての種類のプロジェクトに使用できます。 Gitは、その優れた速度と効率で知られています。 Gitリポジトリは非常に簡単に見つけてアクセスできます。特定の機能により、Gitは柔軟性が高く、安全で、システムと互換性があります。

Q＃2）分散バージョン管理システムとは何ですか？

回答： 分散VCSは、プロジェクトファイルとそのすべてのバージョンを保持するために中央サーバーに依存しないシステムです。分散VCSでは、各共同作業者または開発者がメインリポジトリのローカルコピーを取得します。これはクローンと呼ばれます。

(画像 ソース )

上の図でわかるように、すべての共同作業者はローカルマシンにローカルリポジトリを維持しています。彼らは問題なくローカルリポジトリをコミットして更新することができます。

開発者は、プル操作を使用して、中央サーバーからの最新の変更でローカルリポジトリを更新できます。プッシュ操作を使用して、変更をローカルリポジトリから中央サーバーに送信できます。

Q＃3）Gitを作成したのは誰ですか？

回答： Gitは、Linuxカーネルの開発に向けて2005年にLinusTorvaldsによって作成されました。

Q＃4）Gitではどの言語が使用されていますか？

回答： Cは、Gitが記述されている基礎となるプログラミング言語です。 C言語は、他の高級プログラミング言語にリンクされているランタイムオーバーヘッドを回避することで、Gitを高速化します。

Q＃5）Gitの利点/主な機能は何ですか？

回答：以下に参加しているのはさまざまなfです Gitのeatures。

（i）無料およびオープンソース：

Gitは、GPL（General Public License）のオープンソースライセンスに基づいて発行されます。 Gitを使用するために何も支払う必要はありません。

それは絶対に無料です。オープンソースなので、必要に応じてソースコードを変更できます。

（ii）速度：

すべてのアクションを実行するためにネットワークに接続する必要がないため、すべてのタスクを迅速に実行します。ローカルに保存されたリポジトリからバージョン履歴を取得することは、リモートサーバーから取得するよりも100倍高速です。

GitはCで記述されています。これは、他の高級言語にリンクされたランタイムオーバーヘッドを回避する基盤となるプログラミング言語です。

（iii）スケーラブル：

Gitは非常にスケーラブルです。そのため、今後、共同編集者の数が増えた場合、Gitはこの変更に簡単に対応できます。

Gitはリポジトリ全体を表すという事実にもかかわらず、Gitはロスレス圧縮技術によって膨大なデータ全体を圧縮するため、クライアント側に保持されるデータは非常に小さくなります。

（iv）信頼できる：

すべての共同作業者は独自のローカルリポジトリを持っているため、システムクラッシュが発生した場合、失われたデータを任意のローカルリポジトリから復元できます。常に、すべてのファイルのバックアップがあります。

（v）安全：

Gitは、SHA1（Secure Hash Function）を利用して、リポジトリ内のオブジェクトに名前を付けて識別します。各アーティファクトとコミットはチェックサムされ、チェックアウト時にチェックサムを通じて回復されます。

Git履歴は、特定のバージョンのID（Gitに関するコミット）がそのコミットまでの開発履歴全体に依存するように保存されます。ファイルバージョンがGitにプッシュされると、気付かれずにそれを変更する方法はありません。

（vi）経済的：

集中型バージョン管理システムの場合、中央サーバーはチーム全体の要求に対応できる十分な強度を備えている必要があります。これは小規模なチームにとっては問題ではありませんが、チームが拡大するにつれて、サーバーのハードウェアの制限がパフォーマンスの妨げになる可能性があります。

Gitのような分散バージョン管理システムの場合、チームメンバーは、変更をプッシュまたはプルする必要がある場合に、サーバーとの対話を必要としません。すべての手間のかかる作業はクライアント側で行われるため、サーバーハードウェアを非常にシンプルに保つことができます。

（vii）非線形開発をサポート：

Gitは、迅速な分岐とマージを提供し、非線形の開発履歴を想定してトラバースするための特定のツールを備えています。 Gitの基本的な概念は、変更が異なるレビューアに送信されるときに、変更が書き込まれるよりも頻繁にマージされるというものです。

Gitブランチは非常に軽量です。 Gitのブランチは、単一のコミットのみを参照します。親コミットを使用して、完全なブランチ構造を作成できます。

（viii）簡単な分岐：

Gitによるブランチ管理は非常に簡単で簡単です。ブランチを作成、削除、およびマージするには、ほんの数回の操作が必要です。機能ブランチは、コードベースへの各変更に絶縁された環境を提供します。

開発者が作業のサイズに関係なく、何かに取り組み始める必要がある場合、開発者は新しいブランチを作成します。これにより、マスターブランチが常に本番品質のコードを保持するようになります。

（ix）分散開発：

Gitは、すべての開発者に開発履歴全体のローカルコピーを提供し、さらに変更はそのようなリポジトリから別のリポジトリに複製されます。これらの変更は、追加の開発ブランチとして導入され、ローカルで開発されたブランチと同じ方法でマージできます。

（x）現在のシステムまたはプロトコルとの互換性：

リポジトリは、プレーンソケットまたはsshのいずれかの上で、HTTP、FTP、またはGitプロトコルを介して公開できます。

Q＃6）Gitでリポジトリを作成するにはどうすればよいですか？

回答： リポジトリを作成するには、プロジェクトのディレクトリがまだ存在しない場合は作成してから、コマンド「」を実行する必要があります。 git init 」。このコマンドを実行すると、プロジェクトディレクトリ内に.gitディレクトリが作成されます。つまり、プロジェクトディレクトリがGitリポジトリになります。

Q＃7）.gitディレクトリとは何ですか？

回答： リポジトリを作成すると、その中に.gitディレクトリがあります。この.gitディレクトリには、リポジトリのすべてのメタデータが含まれており、コミット履歴を保持することにより、リポジトリ内のファイルに加えられたすべての変更の追跡を維持します。

コミット、フック、参照、オブジェクトデータベース、リモートリポジトリアドレスなどに関するすべての情報は、このフォルダ内に保持されます。これはGitの最も重要な部分です。ローカルマシンにGitリポジトリのクローンを作成する場合、この.gitは実際にコピーされるディレクトリです。

Q＃8）.gitディレクトリが削除されるとどうなりますか？

回答： .git /ディレクトリが削除されると、プロジェクトの履歴を追跡できなくなります。リポジトリはバージョン管理されなくなります。

Q＃9）Gitでコミットメッセージを書き込むために使用されるコマンドはどれですか？

回答： メッセージをgitcommitに渡すために使用されるコマンドは次のとおりです。 git commit-m「コミットメッセージ」。 旗 m コミットメッセージを渡すために使用されます。

Q＃10）ベアGitリポジトリとは何ですか？標準/非ベアGitリポジトリとどう違うのですか？

回答： を通じて作成されたリポジトリ git init コマンドは、標準/非ベアGitリポジトリです。

このようなリポジトリの最上位フォルダには、次の2つがあります。

1. すべてのメタデータを保持し、リポジトリの履歴を追跡する.gitサブディレクトリ。
2. 作業ツリー。

を使用して作成されたリポジトリ git init –bare コマンドはベアGitリポジトリとして知られています。それらは主に共有に使用されます。作業ツリーは含まれていません。リポジトリのgitリビジョン履歴は、.gitサブフォルダ内ではなく、ルートフォルダに保持されます。

裸のリポジトリデータが含まれているだけです。これが、ベアGitリポジトリが標準のGitリポジトリとどのように異なるかです。また、ベアリポジトリにはデフォルトのリモートがありません 原点 複数のリモートユーザーのオリジンリポジトリとして機能するリポジトリ。

ベアリポジトリにはワークスペースが含まれていないため、 git push そして git pull コマンドは、ベアリポジトリでは機能しません。ベアリポジトリに変更をコミットする必要はありません。

Q＃11）Gitリポジトリホスティングサービスについて言及してください。

回答：

• Github
• ピカコード
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• 発射台
• PERFORCE
• Beanstalk
• のように見えます

Q＃12）Gitの基本的な操作をいくつか挙げてください。

回答： Gitの基本的な操作には次のものがあります。

• 初期化
• 追加
• コミット
• 押す
• 引く

Q＃13）Gitの高度な操作をいくつか挙げてください。

回答： Gitのいくつかの高度な操作は次のとおりです。

• 分岐
• マージ
• リベース

Q＃14）GitとSVNをどのように区別しますか？

回答： Gitは分散バージョン管理ですが、SVNは一元化されています。これにより、機能と機能の点で2つの間に多くの違いが生じます。

Q＃15）GitとGitHubをどのように区別しますか？

回答： Gitは高品質のバージョン管理システムです。これは本質的に配布されており、ソフトウェア開発全体を通じてソースコードの変更を追跡するために使用されます。開発者間の作業の同期とファイルの変更の追跡に役立つ独自の分岐モデルがあります。

Gitの主な目標は、速度とデータの整合性であり、分散型の非線形ワークフローをサポートします。 Gitは、クラウドではなくローカルマシンにインストールされ、維持されます。

GitHubは、チームをまとめるクラウドベースのGitリポジトリホスティングサービスです。 WebベースのGUIを提供するだけでなく、アクセス制御と多くのコラボレーション機能、各プロジェクトの基本的なタスク管理ツールを提供します。

また、GitHubはオープンソースです。つまり、コードは一元化されたサーバーに保持され、誰でもアクセスできます。

Q＃16）Gitの競合とは何ですか？どのように解決しますか？

回答： Gitには、コードの変更が異なる行および異なるファイルで発生した場合に、マージコミットを独自に処理する自動マージ機能があります。

ただし、ファイルの同じコード行に変更があった場合、またはファイルが1つのブランチで削除されたが、別のブランチで存在および変更された場合、コミットを競合する場合、Gitは差異を自動的に解決できないため、マージの競合が発生します。

このような場合、どのコードを含めるか、どのコードを最終マージで破棄するかを決定するためにあなたの助けが必要です。

マージの競合は、ブランチのマージ、ブランチのリベース、またはコミットのチェリーピック中に発生する可能性があります。競合が検出されると、Gitは競合している領域を強調表示し、解決するように求めます。競合が解決されたら、マージを続行できます。

競合する回線変更マージの競合を解決するには、以下の手順に従います。

1. Git Bash（Gitコマンドライン）を開きます。
2. 使用する CD マージの競合が発生しているローカルGitリポジトリに移動するコマンド。
3. 使用 gitステータス マージの競合の影響を受けるファイルのリストを作成するコマンド。
4. 使用しているテキストエディタを開き、マージの競合があるファイルに移動します。
5. ファイル内のマージ競合の開始を確認するには、ドキュメントで競合マーカーを探します<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>>支店名。
6. ブランチの変更のみを保持する必要がある場合、他のブランチの変更のみを保持する必要がある場合、または2つのブランチからの変更を含む可能性のある新しい変更を行う必要がある場合に選択します。競合マーカーを消去します<<<<<<>>>>>>そして、最終的なマージで必要な変更を行います。
7. 使用する gitが追加します。 変更を追加またはステージングするコマンド。
8. 最後に、 git commit -m“ message” コメントを使用して変更をコミットするコマンド。

削除されたファイルマージの競合を解決するには、次の手順に従う必要があります。

1. Git Bash（Gitコマンドライン）を開きます。
2. 使用する CD マージの競合があるローカルGitリポジトリに移動するコマンド。
3. 使用 gitステータス マージの競合の影響を受けるファイルのリストを作成するコマンド。
4. 使用しているテキストエディタを開き、マージの競合があるファイルに移動します。
5. 削除したファイルを保持するかどうかを選択します。削除したファイルで行われた最新の変更は、テキストエディタで確認できます。
6. 使用する git add 削除したファイルをリポジトリに追加するコマンド。または、使用する rmに行く リポジトリからファイルを削除するコマンド。
7. 最後に、 git commit -m“ message” コメントを使用して変更をコミットするコマンド。

Q＃17）壊れたコミットをどのように修正しますか？

回答： 壊れたコミットを修正したり、最後のコミットを変更したりするには、次のコマンドを使用するのが最も便利な方法です。 git commit -amend ’ 。

まったく新しいコミットを作成する代わりに、段階的な変更を前のコミットと組み合わせることができます。これにより、最新のコミットが修正されたコミットに置き換えられます。

(画像 ソース )

このコマンドを使用して、スナップショットを変更せずに前のコミットメッセージを編集することもできます。

Q＃18）git instawebの用途は何ですか？

回答： これは、Webブラウザーで作業中のGitリポジトリーを即座に参照できるスクリプトです。

Javaで多次元配列を宣言する方法

このスクリプトは、ローカルリポジトリを参照するようにgitwebとWebサーバーを設定します。 Webブラウザに自動的に指示し、インターフェイスを介してローカルリポジトリにWebサーバーを実行します。

Q＃19）git is-treeとは何ですか？

回答： 「gitis-tree」 ブロブまたはツリーのSHA-1値とともに、すべてのアイテムのモードと名前で構成されるツリーオブジェクトを示します。

Q＃20） すでにプッシュされて公開されているgitcommitを元に戻す方法はありますか？

回答： はい、不正なコミットを修正または元に戻すには、シナリオに基づいて使用できる2つのアプローチがあります。

彼らです：

1. 非常に明白な方法は、不良ファイルを削除するか、ファイル内のエラーを修正する新しいコミットを作成することです。完了したら、それをリモートリポジトリにプッシュできます。
2. もう1つのアプローチは、新しいコミットを作成して、前の不正なコミットで行われたすべての変更を元に戻すことです。これは、git revertコマンドを使用して実行できます–「 git revert '

Q＃21） gitpullとgitfetchをどのように区別しますか？

回答： Gitプル コマンドは、中央リポジトリの特定のブランチからすべての新しいコミットをプルし、ローカルリポジトリのターゲットブランチを最新のものにします。

Gitフェッチ また、同じことを目指していますが、その基本的な機能は少し異なります。 gitフェッチを実行すると、特定のブランチからのすべての新しいコミットが中央リポジトリにプルされ、これらの変更はローカルリポジトリの新しいブランチに保存されます。これは、フェッチされたブランチと呼ばれます。

ターゲットブランチでこれらの変更を確認したい場合は、を実行する必要があります。 マージする gitフェッチ後。ターゲットブランチは、フェッチされたブランチとマージした後にのみ、最新の変更で更新されます。

そのため、git pullはローカルブランチをリモートバージョンで最新の状態にしますが、gitfetchは自分のローカルブランチまたは作業コピーを直接変更しません。 refs / heads。 Gitフェッチを使用して、下のリモートトラッキングブランチを更新できます refs / remotes //。

簡単に言えば、 git pullは、gitfetchとそれに続くgitmergeに等しい 。

Q＃22）Gitでのステージング領域またはインデックス作成の使用は何ですか？

回答： Gitの観点からは、ファイルの変更を保持できる3つの領域、つまり、作業ディレクトリ、ステージング領域、およびリポジトリがあります。

まず、コンピュータのファイルシステムに保存されているプロジェクトの作業ディレクトリに変更を加えます。すべての変更は、ステージング領域と呼ばれる中間領域に追加するまでここに残ります。

実行することで変更をステージングできます gitadd。 コマンド。このステージング領域では、次のコミットのプレビューが表示され、基本的にコミットを微調整できます。コミットするバージョンに満足するまで、ステージング領域で変更を追加または削除できます。

変更を確認し、変更されたステージを承認すると、最終的に変更をコミットできます。コミットすると、ローカルリポジトリ、つまり.git / objectsディレクトリに移動します。

Git GUIを使用している場合は、変更をステージングするオプションが表示されます。以下のスクリーンショットでは、ファイルsample.txtがステージングされていない変更領域の下にあります。これは、ファイルが作業ディレクトリにあることを意味します。

ファイルを選択して「ステージ変更」をクリックすると、ステージング領域に移動します。 例えば 、ファイルhello.txtは、ステージ変更された（コミットされる）領域に存在します。変更を確認してからサインオフを実行してから、コミットを実行できます。

gitは、これら3つの領域にわたるファイルの変更を追跡するためにインデックスファイルを維持するため、ステージングは​​インデックス作成とも呼ばれます。ステージングされているファイルは現在インデックスにあります。

ステージング領域に変更を追加すると、インデックスの情報が更新されます。コミットを実行すると、実際には、作業ディレクトリにあるものではなく、コミットされるインデックスにあるものになります。あなたは使用することができます gitステータス インデックスの内容を確認するコマンド。

Q＃23）Git Stashとは何ですか？

回答： GIT stashは、作業ディレクトリとインデックスの現在の状態をキャプチャし、将来の使用のためにスタックに保持します。コミットされていない変更（ステージングされたものとステージングされていないものの両方）を作業ディレクトリから元に戻し、クリーンな作業ツリーを返します。

今すぐ他の作業を行うことができ、戻ってきたときにこれらの変更を再適用できます。したがって、現在の変更を失うことなく、あるコンテキストから別のコンテキストに切り替えたい場合は、スタッシングを使用できます。

コード変更の途中で、今すぐコミットしたり元に戻したりしたくなく、他に作業する必要がある場合に、コンテキストをすばやく切り替えるのに役立ちます。使用するコマンドはgitstashです。

Q＃24）Git Stashドロップとは何ですか？

回答： 特定のスタッシュが不要になったら、実行して削除できます git stashdropコマンド 。リポジトリから一度にすべてのスタッシュを削除したい場合は、実行できます git stashclearコマンド 。

Q＃25）Gitスタッシュとは何ですか？ Git stash popとはどう違うのですか？

回答： 両方のコマンドを使用して、隠された変更を再適用し、離れた場所から作業を開始します。

に git stash apply コマンドを実行すると、変更は作業コピーに再適用され、スタッシュに保持されます。このコマンドは、同じ隠し変更を複数のブランチに適用する場合に使用できます。

に git stash pop コマンドを実行すると、変更がスタッシュから削除され、作業コピーに再適用されます。

Q＃26）git cloneコマンドの用途は何ですか？

回答： ザ・ git clone コマンドは、既存の中央Gitリポジトリのコピーをローカルマシンに作成します。

Q＃27）git configコマンドはいつ使用されますか？

回答： ザ・ git config コマンドは、Gitインストールの構成オプションを設定するために使用されます。

例えば、 Gitをダウンロードした後、以下のconfigコマンドを使用して、Gitでユーザー名とコミットメールアドレスをそれぞれ設定する必要があります。

$ git config –global user.name“”

$ git config –global user.email“”

したがって、主に、リポジトリの動作、ユーザー情報、設定などは、このコマンドを使用して設定できます。

Q＃28）ブランチがすでにマスターにマージされているかどうかをどのように識別しますか？

回答：

以下のコマンドを実行することで、ブランチのマージステータスを知ることができます。

1. gitブランチ–マージされたマスター： これにより、マスターに名前が変更されたすべてのブランチが一覧表示されます。
2. gitブランチ–マージ： これにより、HEADにマージされたすべてのブランチが一覧表示されます。
3. gitブランチ–マージなし： これにより、まだマージされていないすべてのブランチが一覧表示されます。

デフォルトでは、このコマンドはローカルブランチのマージステータスのみを通知します。ローカルブランチとリモートブランチの両方のマージステータスについて知りたい場合は、次を使用できます。 -に 国旗。リモートブランチのみをチェックする場合は、次を使用できます。 -r 国旗。

Q＃29）Gitのフックとは何ですか？

回答： Gitフックは、コミット、プッシュ、更新、受信などのイベントの前後にGitが実行する特定のスクリプトです。ローカルリポジトリの.gitディレクトリ内に「hooks」フォルダがあります。組み込みスクリプトは、pre-commit、post-commit、pre-push、postpushにあります。

これらのスクリプトは、イベントの発生前または発生後にローカルで実行されます。必要に応じてこれらのスクリプトを変更することもでき、Gitはその特定のイベントが発生したときにスクリプトを実行します。

Q＃30）git forkの用途は何ですか？フォークはクローンとどう違うのですか？

回答： プロジェクトをフォークするということは、元のリポジトリのリモートのサーバー側コピーを作成することを意味します。このコピーの名前を変更して、元のプロジェクトに影響を与えることなく、これを中心に新しいプロジェクトを開始できます。フォークはGitのコアコンセプトではありません。

フォーク操作はGitワークフローで使用され、このアイデアはGitHubのような無料のオープンソースソフトウェアでは長く存在します。通常、プロジェクトをフォークすると、親プロジェクトに再び貢献することはめったにありません。

例えば、 OpenBSDは、別のUnixライクなオープンソースOSであるNetBSDをフォークすることによって開発されたUnixライクなオープンソースオペレーティングシステムです。

ただし、フォークでは、フォークされたコピーと元のリポジトリの間に直接接続が存在します。プルリクエストを使用すると、いつでも元のプロジェクトに貢献できます。

フォークされたコピーでは、コードやファイルなどのすべての主要なデータが元のリポジトリからコピーされますが、ブランチ、プルリクエスト、その他の機能はコピーされません。フォークは、オープンソースコラボレーションにとって理想的な方法です。

クローン作成は本質的にGitの概念です。クローンは、リモートリポジトリのローカルコピーです。リポジトリのクローンを作成すると、ソースリポジトリ全体とその履歴およびブランチがローカルマシンにコピーされます。

フォークとは異なり、複製されたリポジトリと元のリモートリポジトリの間には直接接続はありません。プルリクエストを実行して元のプロジェクトに戻る場合は、元のリポジトリに共同編集者として追加する必要があります。

複製されたコピーにもすべてのコミット履歴があるため、複製は元のリポジトリのバックアップを作成するための優れた方法でもあります。

Q＃31）特定のGitコミットで変更されたすべてのファイルをどのように確認しますか？

回答： 特定のコミットのハッシュ値を使用することにより、以下のコマンドを実行して、特定のコミットで変更されたファイルのリストを取得できます。

git diff-tree -r {hash}

これにより、変更されたすべてのファイルと、追加されたファイルが一覧表示されます。 -rフラグは、ルートディレクトリ名のみでファイルを折りたたむのではなく、パスとともに個々のファイルを一覧表示するために使用されます。

以下のコマンドを使用することもできます。

無料のPC修復ツールウィンドウ10

git diff-tree –no-commit-id –name-only -r {hash}

–no-commit-idは、コミットハッシュ番号を再トレーニングして出力に入力します。一方、-nameはファイルパスを除外し、出力にファイル名のみを提供します。

Q＃32） git checkout (ブランチ名)とgitcheckout -b (ブランチ名)の違いは何ですか？

回答： コマンド git checkout (ブランチ名) あるブランチから別のブランチに切り替わります。

コマンド git checkout -b (ブランチ名) 新しいブランチを作成し、それに切り替えます。

Q＃33）SubGitとは何ですか？

回答： SubGitは、SVNからGitへの移行に使用されるツールです。 TMateという会社によって開発されました。 SVNリポジトリをGitに変換し、両方のシステムで同時に作業できるようにします。 SVNをGitと自動同期します。

(画像 ソース )

このツールを使用して、SVN || Gitミラーを作成できます。 SubGitはGitサーバーにインストールする必要があります。 SVNリビジョン、ブランチ、タグなど、リモートSVNリポジトリのすべての設定を検出し、それらをGitコミットに変換します。

また、マージデータの追跡などの履歴も保持されます。

Q＃34）Gitで削除されたブランチを復元できますか？

回答： はい、できます。削除されたブランチを回復するには、頭のてっぺんからSHAを知っている必要があります。 SHAまたはハッシュは、Gitがすべての操作で作成する一意のIDです。

ブランチを削除すると、端末にSHAが表示されます。

削除されたブランチ（だった）

以下のコマンドを使用して、削除されたブランチを回復できます。

git checkout -b

ブランチの先端にあるコミットのSHAがわからない場合は、最初に reflogに行く コマンドでSHA値を確認してから、上記のcheckoutコマンドを適用してブランチを復元します。

Q＃35）とは git diff コマンド？それはどう違うのですか gitステータス？

回答： Git diff は、2つの任意のコミットの違い、作業ツリーとコミットの変更、作業ツリーとインデックスの変更、2つのファイルの変更、インデックスとツリーの変更などを表示するために実行できる多目的コマンドです。

ザ・ gitステータス コマンドは、リポジトリを検査するために使用されます。作業ディレクトリとステージング領域の状態が表示されます。ステージングされたファイル、ステージングされていないファイル、および追跡されていないファイルが一覧表示されます。

Q＃36）Commitオブジェクトには何が含まれていますか？

回答： コミットオブジェクトには、最上位のツリーオブジェクトハッシュ、親のコミットハッシュ（存在する場合）、作成者とコミッターの情報、コミット日、コミットメッセージが含まれます。

あなたはこれを通して見ることができます gitログ コマンド。

例：

(画像 ソース )

Q＃37）git Cherry-pickとは何ですか？ gitcherry-pickを使用できるシナリオは何ですか？

回答： チェリーピックをGit 1つ以上の既存のコミットによって導入された変更を適用するための強力なコマンドです。これにより、あるブランチからコミットを選択して、別のブランチに適用できます。

git Cherry-pick commitSha チェリーピッキングに使用されるコマンドです。 commitShaはコミットリファレンスです。

このコマンドは、変更を元に戻すために使用できます。たとえば、誤って間違ったブランチにコミットした場合は、正しいブランチをチェックアウトして、それが属するべき場所へのコミットを選択することができます。

チームコラボレーションでも使用できます。製品の2つのコンポーネント間で同じコードを共有する必要があるシナリオが存在する可能性があります。この場合、一方の開発者がすでにそのコードを記述している場合は、もう一方の開発者が同じコードを選択できます。

チェリーピッキングは、パッチコミットをマスターブランチに直接チェリーピックして問題をできるだけ早く修正できるバグ修正プログラムでも役立ちます。

Q＃38）「gitreset」は何に使用されますか？このコマンドのデフォルトモードは何ですか？

回答： Gitリセット Gitリポジトリの状態に対するローカルの変更を元に戻すための強力なコマンドです。このコマンドは、現在のHEADを指定されたステージにリセットします。

インデックスと作業ディレクトリの両方を最後のコミットの状態にリセットします。 Gitリセットには、ソフト、ハード、混合の3つのモードがあります。デフォルトの動作モードは混在しています。

Q＃39）「HEAD」、「working tree」、「index」の違いは何ですか？

回答： 作業ツリーまたはワークスペースは、現在作業しているソースファイルを含むディレクトリです。

インデックスは、コミットが準備されるGitのステージング領域です。それはコミットと作業ツリーの間にあります。 Gitインデックスは、現在のブランチ内のすべてのファイル、それらの名前、sha1チェックサム、およびタイムスタンプをリストする1つの大きなバイナリファイルです。

このファイルは/.git/indexにあります。 HEADは、現在のチェックアウトブランチの最新のコミットへの参照またはポインターです。

Q＃40）リベースとマージの違いは何ですか？いつリベースし、いつマージする必要がありますか？

回答： リベースコマンドとマージコマンドはどちらも、あるブランチから別のブランチへの変更を統合するために使用されますが、方法は異なります。

以下の2つの画像に見られるように、コミットがあるとします（これはマージ/リベースの前です）。マージ後、コミットの組み合わせとして結果が得られます。両方のブランチの履歴をバインドし、機能ブランチに新しい「マージコミット」を作成します。

一方、リベースは機能ブランチ全体を移動して、マスターブランチの先端から開始します。

(画像 ソース )

コミットは次のようになります。

リベースは、一貫性のないリポジトリを作成するため、パブリックブランチにはお勧めしません。ただし、リベースはプライベートブランチ/個々の開発者にとっては良いオプションです。機能ごとのブランチモードにはあまり適していません。ただし、開発者ごとのブランチモデルがある場合、リベースは害にはなりません。

また、リベースは破壊的な操作であるため、開発チームはそれを正しく適用するのに十分なスキルを持っている必要があります。そうしないと、コミットされた作業が失われる可能性があります。

さらに、マージを元に戻すことは、リベースを元に戻すよりも簡単です。したがって、元に戻す必要がある可能性があることがわかっている場合は、マージを使用する必要があります。

マージは履歴をそのまま保持しますが、リベースは履歴を書き換えます。したがって、発生した履歴を完全に表示したい場合は、マージを使用する必要があります。

Q＃41）リベースの構文は何ですか？

回答： rebaseコマンドの構文は次のとおりです。 git rebase (new-commit)

Q＃42）ローカルファイルシステムから実際にファイルを削除せずに、Gitからファイルを削除するにはどうすればよいですか？

回答： これには「キャッシュ」オプションを使用できます。

git rm -rf –cached $ FILES

このコマンドは、ディスクからファイルを削除せずに、リポジトリからファイルを削除します。

Q＃43）Gitの一般的な分岐パターンは何ですか？

回答： 一般的な分岐パターンは、git-flowに基づいています。マスターと開発の2つの主要なブランチがあります。

• マスターブランチには、プロダクションコードが含まれています。すべての開発コードは、ある時点でマスターブランチにマージされます。
• 開発ブランチには、実動前のコードが含まれています。機能が完了すると、通常はCI / CDパイプラインを介してマスターブランチにマージされます。

このモデルには、開発サイクル中に使用されるいくつかのサポートブランチもあります。

• 機能ブランチ/トピックブランチ： これらは、今後のリリースの新機能を開発するために使用されます。開発ブランチから分岐する可能性があり、開発ブランチにマージして戻す必要があります。通常、これらのブランチは開発者リポジトリにのみ存在し、元には存在しません。
• 修正プログラムブランチ： これらは、ライブ製品バージョンで重大なバグをすぐに修正する必要がある場合に、計画外の製品リリースに使用されます。それらはマスターから分岐する可能性があり、開発とマスターにマージして戻す必要があります。
• リリースブランチ： これらは、新しい製品リリースの準備に使用されます。リリースブランチでは、マイナーなバグ修正を行い、リリース用のメタデータを準備できます。それらは開発から分岐する可能性があり、マスターにマージして開発する必要があります。

結論

このチュートリアルでは、Gitのインタビュー中に一般的に尋ねられる重要な質問について説明しました。

これは、今後のインタビューの準備に役立つだけでなく、gitの概念を明確にするのにも役立ちます。

面接に最適です！

推奨読書

• 面接の質問と回答
• いくつかの興味深いソフトウェアテストのインタビューの質問
• トップ40のCプログラミング面接の質問と回答
• あなたが読むべきトップ40の人気のあるJ2EEインタビューの質問と回答
• ETLテストの面接の質問と回答
• 20以上の最も一般的に尋ねられる出口面接の質問と回答
• Oracle Forms andReportsの面接に関する上位の質問
• いくつかのトリッキーな手動テストの質問と回答