Git で変更を記録して共有するまでの流れを説明してください

作業ツリー、ステージ、コミット、push の 4 つの置き場で答える問い。add が何をする操作かまで言えると伝わります。

こう聞かれます

  • 「Git で変更を記録して、チームに共有するまでの流れを説明してください」
  • 「git add は何のためにあるのですか。いきなりコミットできないのはなぜですか」
  • 「コミットしたのに、ほかの人から見えないと言われました。何が足りませんか」(裏から聞く形)

面接官が見ている点

  • コマンドの名前を並べるだけでなく、変更が「どこからどこへ」動くかで話せるか
  • add を「保存」と言わず、次のコミットに入れる物を選ぶ操作だと分かっているか
  • コミットは手元の記録で、push して初めて共有される、と区別できているか

短い答え

  • ファイルを直すと、まず手元の作業場所 (作業ツリー) が変わります。
  • git add で次のコミットに入れる変更を選んでステージに載せ、git commit で 1 つの記録として残します。
  • git push で手元のコミットを共有のリポジトリへ送ると、ほかの人も取り込めるようになります。

少し詳しい答え

置き場の動きを確かめる

2 つのファイルを作り、片方だけを add してからコミットし、共有用のリポジトリへ push します。git status --short は、いまの状態を短く出すコマンドです。

ターミナル

git init -q --bare up.git
git init -q -b main demo
cd demo
git config user.name Aya
git config user.email a@x.jp
echo "買い物" > memo.txt
echo "宿題" > todo.txt
git status --short
git add memo.txt
git status --short
git commit -q -m "メモを足す"
git status --short
git remote add origin ../up.git
git push -q origin main
git log --format=%s origin/main
?? memo.txt
?? todo.txt
A  memo.txt
?? todo.txt
?? todo.txt
メモを足す

?? はまだ Git が見ていないファイル、A はステージに載った新しいファイルの印です。add しなかった todo.txt は、コミットのあとも作業ツリーに残ったままです。最後の行は、共有側のリポジトリにコミットが届いたことを示しています。

add があるわけ

ステージがあるので、作業ツリーにある直しのうち、ひとまとまりの物だけを選んでコミットできます。たとえば「ボタンの色の直し」と「試しに書いたメモ」が混ざっていても、前者だけを 1 つのコミットにできます。1 つのコミットに 1 つの目的があると、あとで履歴を読むときや戻すときに迷いません。

作った物と結ぶなら、たとえば「ポートフォリオの開発では、画面の直しと設定の直しを別々に add してコミットし、1 日の終わりに push していました」のように話します。

よくある間違い

  • 「add はファイルを保存すること」と言う add は次のコミットに入れる変更を選ぶ操作です。記録として残るのはコミットのときです
  • 「コミットすればチームに共有される」と言うコミットは手元のリポジトリの記録です。push するまで、ほかの人には届きません
  • 何でも git add . でまとめて入れると話す 関係の無い変更や、入れてはいけないファイルまで混ざります。status や diff で中身を見てから選ぶ、と添えます

深掘りの問い

  • 「push する前に、いまの状態や直した中身を確かめるには」 git status で置き場の状態を、git diff で直した行を見る、と答えます
  • 「パスワードを書いた設定ファイルをコミットしないようにするには」 .gitignore に書いて Git に見せない、と答えます。一度 push した秘密は履歴に残るので、鍵そのものを取り替える、とも添えます
  • 「push したら断られました。何が起きていますか」共有側に自分の持っていないコミットがある、と答えます。先に pull で取り込んでから push し直します

確認日 2026年10月23日

技術面接問題の一覧へ戻る