あらゆるレベル向け Git 面接の質問と回答トップ25

基礎的な Git 面接質問

Git を使い始めたばかりの場合、面接では基本的な概念や使い方が問われることが多いでしょう。復習が必要であれば、DataCamp の Introduction to Git コースを確認してください。

Git リポジトリとは何ですか？

Git リポジトリは、プロジェクトのファイルと変更履歴を保存し、時間の経過とともに行われた変更を追跡することでバージョン管理を実現します。リポジトリはローカル（デバイス上のフォルダ）にも、GitHub のようなオンラインプラットフォーム上にも作成できます。これにより、ユーザーは共同作業を行い、以前のバージョンに戻し、commit、push、pull といったコマンドを使って効率的に開発を管理できます。

Git はどのように動作しますか？

Git は、プロジェクト内のファイルやディレクトリに対する変更を記録し、その時点のスナップショットを保存することで動作します。ユーザーは変更を管理し、並行開発のためにブランチを作成し、ブランチをマージし、必要に応じて以前の状態に戻すことができます。これにより、共同開発が促進され、ソフトウェア開発における効果的なバージョン管理が実現します。

git add とは何ですか？

git add コマンドは、次のコミットに含める変更をステージするために使用します。作業ディレクトリで行った変更・追加・削除を次のコミットのスナップショットに含める対象としてマークします。なお、このコマンド自体はコミットを実行せず、ステージングの準備のみを行います。

git push とは何ですか？

git push コマンドは、ローカルリポジトリの内容をリモートリポジトリにアップロードするために使用します。通常は GitHub や GitLab のようなサーバー上のリモートに対して、ローカルでコミット済みの変更を転送します。このコマンドにより、同じプロジェクトで作業する他の人と変更を共有でき、コラボレーションが可能になります。

詳しくは、別チュートリアル「Git の push と pull」をご覧ください。

git status とは何ですか？

git status コマンドは、Git におけるリポジトリの現在の状態を表示します。どのファイルが変更されているか、どれが次のコミット用にステージされているか、どれが未追跡かといった情報を提供します。作業の進捗を把握し、コミットやステージが必要な変更を特定するのに役立ちます。

Git におけるコミットとは何ですか？

コミットは、ある時点でリポジトリ内のファイルに加えられた変更のスナップショットを表します。Git で変更をコミットすると、ファイルの現在の状態が保存され、推奨されるやり方として、その変更内容を説明するメッセージを付けることができます。

各コミットには一意の識別子が付与され、リポジトリ内の変更履歴を追跡できます。コミットはバージョン管理において重要な役割を果たし、プロジェクトを以前の状態に戻したり、変更履歴を確認したり、更新内容を共有して他者と協業したりすることを可能にします。

面接対策には DataCamp の Git チートシートもご活用ください

Git のブランチとは何ですか？

ブランチングとは、メインの開発ライン（一般に main、以前は master と呼称）から分岐し、メインコードベースに影響を与えずに新機能や修正、検証を行うことを指します。これにより、同じリポジトリ内で複数の開発ラインを並行して進められます。

各ブランチは独立した開発ラインであり、独自のコミット履歴を持ちます。これにより、開発者は別々の機能や修正に同時並行で取り組めます。ブランチングは、コラボレーション、検証、プロジェクト内の整理を容易にし、変更が完了してテストが済んだらメインコードベースにマージできます。

Git におけるコンフリクトとは何ですか？

コンフリクトは、異なる貢献者がファイルの同じ箇所に対して矛盾する変更を行ったとき、主にマージやリベースの際に発生します。Git はこれらの衝突を自動的には解決できないため、ユーザーが手動で不一致を解消する必要があります。

コンフリクトを解決するには、該当ファイルを開くと、Git が衝突箇所に <<<<<<<、=======、>>>>>>> のマーカーを付けています。正しい内容を残すように編集し、マーカーを削除してから次を実行します。

git add <resolved-file>
git commit

Git におけるマージとは何ですか？

マージは、プロジェクト内の異なるブランチでの変更を統合し、共同作業を促進するための Git の基本操作です。具体的には、異なるブランチの変更を1つのブランチ、通常はメインブランチ（例：master または main）に統合するプロセスです。

マージは、一方のブランチで行われた変更を別のブランチに取り込み、両ブランチの履歴を統合する新しいコミットを作成します。マージコンフリクトの解決方法については、別のチュートリアルで詳しく学べます。

中級レベルの Git 面接質問

Git におけるリモートとは何ですか？

リモートとは、共同作業やコード共有のためにサーバーや別のコンピュータにホストされたリポジトリのことです。開発者がローカルの変更を push したり、他者の変更を pull したりするための集約された場所として機能します。

リモートは一般に GitHub、GitLab、Bitbucket といったホスティングプラットフォーム上に設定され、分散開発を可能にし、複数の貢献者間でプロジェクトのコードを保存・同期する共通の場所を提供することでチームワークを円滑にします。

すでに push され公開されているコミットをどのように取り消しますか？

git revert <commit-hash> コマンドを使うと、すでに push 済みで公開されているコミットを取り消せます。

手順は次のとおりです。

1. 取り消したいコミットを、そのハッシュ値で特定します。git log コマンドで履歴を表示し、対象のコミットハッシュを探します。

2. コミットハッシュが分かったら、git revert コマンドに続けてそのハッシュを指定し、該当コミットの変更を打ち消す新しいコミットを作成します。例：

git revert <commit-hash>

3. Git がテキストエディタを開き、revert 用のコミットメッセージを作成します。必要に応じて編集し、保存してエディタを閉じます。

4. メッセージを保存すると、指定したコミットによる変更を打ち消す新しいコミットが作成され、履歴に追加されます。

5. 最後に、次のコマンドで新しいコミットをリモートに push して、取り消しを公開します。

git push origin <branch-name> 

git revert は、元のコミットの変更を打ち消す新しいコミットを作成し、履歴を改変せずに取り消します。これは、履歴を書き換えてしまう git reset や git amend よりも安全で、すでに変更を pull 済みの共同作業者に問題を引き起こしにくい方法です。

git stash とは何ですか？

git stash は、まだコミットする準備ができていない作業ディレクトリの変更を一時的に保存する Git コマンドです。変更をリポジトリにコミットせずに退避しておけます。

ブランチを切り替える必要があるが、変更をコミットしたくない、あるいは失いたくない場合に便利です。後から、退避した変更を作業ディレクトリに適用したり、スタッシュスタックから取り出して作業を再開したりできます。

git reflog とは何ですか？

git reflog は、HEAD ポインタの移動やリポジトリでチェックアウトされたコミットの履歴など、参照ログを表示するための Git コマンドです。コミット、チェックアウト、マージ、リセットなど、直近の操作の時系列リストを提供します。

reflog は、失われたコミットやブランチの復旧、またはリポジトリで行われた操作の順序を把握するのに役立ちます。

既存の Git ブランチをリモートブランチの追跡対象にするには？

既存の Git ブランチをリモートブランチの追跡対象にするには、git branch コマンドで --set-upstream-to または -u オプションを使用し、リモートブランチ名を指定します。

構文は次のようになります。

git branch --set-upstream-to=<remote-name>/<branch-name>

または

git branch -u <remote-name>/<branch-name>

上級レベルの Git 面接質問

プロジェクトごとに異なる設定を Git でどのように管理しますか？

さまざまな設定に対応するには、git config コマンドで --global、--system、--local フラグを使い、設定レベルごとに調整します。あるいは、Git の設定で includeIf を使用し、リポジトリのパスに基づいて特定の設定を取り込む方法も有効です。

Git で大きなファイルをどのように扱いますか？

大きなファイルは、リポジトリサイズやパフォーマンスに影響するため扱いが難しいことがあります。Git LFS を使用して、大きなファイルを Git リポジトリ外に保存し、リポジトリ内には軽量なポインタのみを保持します。これによりリポジトリのサイズを削減し、パフォーマンスを向上できます。Git LFS はさまざまなストレージプロバイダをサポートし、Git のワークフローとシームレスに統合されます。

git submodule の使い道は何で、どのように更新しますか？

git submodule コマンドは、Git リポジトリ内で外部の依存関係を管理します。メインリポジトリ内に外部リポジトリをサブモジュールとして組み込むことができます。外部ソースのコードを取り込みつつ、メインプロジェクトのコードベースとは切り分けておきたい場合に有用です。

Git でサブモジュールを更新する手順は次のとおりです。

1. メインリポジトリ内のサブモジュールのディレクトリに移動します。

2. git fetch でサブモジュールのリモートリポジトリから最新の変更を取得します。

3. サブモジュールが追跡しているブランチの最新コミットに更新したい場合は、git pull を使用します。

4. 特定のコミットやブランチに更新したい場合は、git checkout に続けて目的のコミットハッシュまたはブランチ名を指定します。

5. サブモジュールを目的の状態に更新したら、更新されたサブモジュールの状態を反映するためにメインリポジトリでコミットします。

git cherry-pick とは何で、いつ使いますか？

git cherry-pick は、ブランチ全体をマージせずに、特定のコミットだけを別のブランチに適用するためのコマンドです。

git cherry-pick <commit-hash>

誤って別のブランチにコミットしてしまった場合にも有用です。正しいブランチに cherry-pick し、不要な方ではそのコミットを取り消します。

git bisect とは何で、何に使いますか？

git bisect は、二分探索を用いて、バグを導入した特定のコミットを特定するデバッグツールです。コミットを1つずつ手動でチェックアウトする代わりに、バグのない「良い」コミットと、バグのある「悪い」コミットを Git に伝えると、Git がその間のコミットを順にチェックアウトし、探索範囲を半分ずつ狭めて原因のコミットを突き止めます。

git bisect start
git bisect bad                # 現在のコミットにはバグがある
git bisect good <commit-hash> # この以前のコミットは正常
# Git が中間のコミットをチェックアウト。テストしてから：
git bisect good   # または git bisect bad
# Git が最初の不良コミットを特定するまで繰り返す
git bisect reset  # 終了後は元の状態に戻す

大規模でコミット数の多いリポジトリでは、手動探索よりはるかに高速です。

Git フックとは何で、どのように使いますか？

Git フックは、Git のワークフローの特定のタイミングで自動的に実行されるスクリプトです。リポジトリの .git/hooks/ ディレクトリに配置され、任意のスクリプト言語で記述できます。

フックには2種類あります。

• クライアントサイドフックはローカル環境で実行されます。例：pre-commit（コミット作成前に実行）、commit-msg（コミットメッセージの形式を検証）。

• サーバーサイドフックはリモートサーバーで実行されます。例：pre-receive（push されたコミットを受け付ける前に実行）。

一般的な使い方として、pre-commit フックでコミット前にリンターやテストを自動実行し、チーム全体のコード品質基準を担保する方法があります。

なお、フックはリポジトリをクローンしても自動的にはコピーされません。フックに依存するチームでは、別スクリプトや pre-commit（Python パッケージ）のようなツールで共有するのが一般的です。

混同しやすい Git の概念に関する質問

git fetch と git pull の違いは何ですか？

git fetch と git pull の主な違いは、処理内容とローカルリポジトリの更新方法にあります。

git fetch は、リモートリポジトリの変更をローカルリポジトリに取得します。ローカルのリモート追跡ブランチ（例：origin/master）をリモートの最新状態に更新しますが、作業ディレクトリを更新したり、現在のブランチにマージしたりはしません。つまり、fetch 後はローカル作業に影響を与えずに、リモートの変更内容を確認できます。

git pull もリモートから変更を取得しますが、fetch に加えて、その変更を現在のブランチにマージするところまでを1回で行います。実質的に、git fetch の後に git merge を実行して、リモートの変更を現在のブランチに取り込みます。

git reset は何をしますか？

git reset コマンドは、現在の HEAD を指定した状態にリセットします。これにより、変更の取り消し、ステージ解除、HEAD ポインタの移動などが可能です。git reset には主に3つのモードがあります。

• --soft: HEAD ポインタだけを指定のコミットに移動し、変更はステージされたままにします。作業ディレクトリの変更は維持され、再コミットできます。

• --mixed: HEAD を指定のコミットに移動し、変更のステージを解除します。作業ディレクトリの変更は残りますが、コミット用にステージされていません。

• --hard: HEAD を指定のコミットに移動し、作業ディレクトリとステージングエリアの変更をすべて破棄します。未コミットの変更が完全に失われるため注意が必要です。

重要: 共有のリモートブランチにすでに push 済みのコミットに対しては、git reset --hard を決して使用しないでください。履歴が書き換えられ、すでにそのコミットを pull したチームメイトに深刻な問題を引き起こします。公開済みのコミットには代わりに git revert を使用してください。

git push --force と比べて git push --force-with-lease の重要性は何ですか？

git push --force-with-lease は、git push --force よりも慎重な強制 push の方法であり、リモートで他者が加えた変更を誤って上書きするのを防ぎます。

git push --force を使うと、最後に fetch して以降に他者が更新していても、それを考慮せずに強制的に変更を push してしまいます。これにより、他の開発者の作業を意図せず失わせる恐れがあります。

一方、git push --force-with-lease はより安全です。push 先のリモートブランチが最後の fetch 以降に他者によって更新されていないかを確認し、更新されていれば push を拒否して、他者の変更をうっかり上書きするのを防ぎます。

git rebase とは何で、git merge とどう違いますか？

git rebase と git merge は、いずれも一方のブランチの変更をもう一方に取り込みますが、その方法が異なります。

• git merge は、新しい「マージコミット」を作って2つのブランチの履歴を結合します。分岐と統合の履歴が完全に保持されるため、監査やチームの透明性に役立ちます。

• git rebase は、あるブランチのコミットを別のブランチの先頭に移動（リプレイ）し、マージコミットのないクリーンで直線的な履歴を作ります。ログが読みやすくなりますが、コミット履歴を書き換えるため、リベースの黄金律は「他人が作業しているブランチは決してリベースしない」ことです。

git clone と git fork の違いは何ですか？

クローンは、リモートリポジトリのローカルコピーを作成します。同じリポジトリに接続された状態で、権限があれば変更を push できます。

git clone https://github.com/user/repo.git

フォークは、元のリポジトリへの直接書き込み権限がないオープンソースプロジェクトに貢献する標準的なワークフローです。

Git 面接の準備

面接で Git に関する知識や経験を適切に伝えることは、バージョン管理とチームでのコラボレーション能力を示すうえで非常に重要です。

技術面接に向けて Git スキルを効果的に伝えるためのヒントをいくつか紹介します。

Git の基礎を理解する

リポジトリ、ブランチ、マージ、コミット、pull、push、clone、commit といった基本コマンドなど、Git の基礎をしっかり理解してください。これらの基礎知識が、面接での議論の土台になります。また、バージョン管理の基本原則を把握し、Git と他のバージョン管理システムの違いを理解しておくことも役立ちます。

最後に、Git Flow、GitHub Flow、GitLab Flow といったさまざまな Git の運用手法にも慣れておきましょう。それぞれの長所と短所を評価し、どのような状況で最も有効かを見極めてください。

基礎を身につけるには、Git の完全ガイドが良い出発点です。

実践経験を積む

Git を使えば使うほど、知識は定着します。定期的な練習は、さまざまなコマンドや手順への習熟を促します。日々のワークフローに Git を取り入れて経験を積みましょう。ブランチの作成、マージ、コンフリクト解消などを積極的に試してください。

どのようなプロジェクトで実践経験を積むべきか迷う場合は、GitHub などのプラットフォームでオープンソースに参加するのが有効です。業界標準のコラボレーションツールやワークフローを実地で体験できます。

よくある問題とトラブルシューティングを学ぶ

Git を使っていると、問題に遭遇するのは避けられません。代表的なものに、マージコンフリクト、detached HEAD、変更の取り消し、失われたコミットの復旧などがあります。Git の問題を診断することで、トラブルシューティング能力が高まり、Git の仕組みへの理解も深まります。

エラーメッセージを読み解いて積極的に対処することで、Git の内部動作への洞察が得られ、問題の特定と解決を効率的に行えるようになります。こうした姿勢は、リスクの低減に加え、バージョン管理ワークフローを扱う自信と専門性の向上にもつながります。

模擬面接を実施する

模擬面接に取り組むことで、Git に関する知識やコミュニケーション面の弱点を洗い出せ、効果的な準備に集中できます。

さらに、現実的な Git のシナリオやコーディング演習に取り組む貴重な機会にもなります。実践を通じて Git スキルに自信がつき、面接で自分の考えを明瞭に伝える力が高まります。

結論

Git は、コード変更の管理、他者とのコラボレーション、プロジェクト履歴の維持に広く使われる強力なバージョン管理システムです。Git に精通していることは、開発者に必須のツールやワークフローに習熟している証であり、協働スキルやチーム環境でコードを適切に管理する能力を示すため、技術面接において重要です。

また、Git の概念やコマンドを理解していれば、効率的なバージョン管理を実践でき、コードの完全性、プロジェクトの継続性、開発プロセスの効率化が図れます。そのため、Git の知識は、技術面接に臨む将来のソフトウェアエンジニアや開発者にとって非常に価値があります。

さらに学ぶには、以下のリソースをご覧ください。

• Git とは？– Git 完全ガイド
• GitHub と Git の初心者向けチュートリアル
• GitHub の基本概念
• Git チートシート 完全版