Gitコマンドを整える。

A. **git add** は作業ツリーの変更を「次のコミットに入れる候補」としてステージへ移すだけで、履歴にはまだ何も記録されません。**git commit** は、そのステージの内容をスナップショットとしてローカルリポジトリの履歴に記録するコマンドです。addで候補を選び、commitで確定する、という2段階になっています。図の①でこの流れを確認できます。

A. **git fetch** はリモートの最新情報を取ってくるだけで、ローカル内の「origin/main」という記録用の参照を更新するだけです。作業ツリーやブランチの中身は変わりません。**git pull** は多くの場合「fetch＋merge」をセットで行い、取得した内容を今のブランチに取り込み、作業ツリーのファイルも最新化します（設定によってはmergeの代わりにrebaseになります）。「pullしたのに変わらない」の逆に「fetchしたのに反映された気がする」という思い込みが、この2つを混同する典型的な原因です。図の②で反映されるタイミングの違いを確認できます。

A. 正確には違います。git resetは「**HEAD（今いる位置）をどのコミットに動かすか**」を指定するコマンドで、何個前のコミットにも動かせます。`--soft`はHEADだけ、`--mixed`（既定）はHEADとステージ、`--hard`はHEAD・ステージ・作業ツリーの3つすべてを動かします。**--hardは保存されていない作業ツリーの変更を消す**ため、実行前に注意が必要です。図の③で3種類の違いを確認できます。

A. resetはHEAD（今いる位置）そのものを動かし、動かした先より新しいコミットは（すぐには）見えなくなります。revertは逆に、指定したコミットの内容を打ち消す**新しいコミットを追加**するだけで、元のコミットは履歴に残ります。共有済み（push済み）の履歴を戻したいときは、履歴を書き換えないrevertの方が安全とされています。

A. checkoutは今も動きますが、現在は役割ごとに専用コマンドが用意されています。**git switch**はブランチの移動、**git restore**はファイルの復元（直前のコミットやステージの内容に戻す）を担当します。checkoutは元々この両方を1つのコマンドで担っていたため、目的を分かりやすくするために分割されました。図の④で切替の様子を確認できます。

A. mergeは2つのブランチの変更を取り込んだ「マージコミット」を新しく作り、元のコミットはそのまま残して履歴を1本にまとめます。rebaseは自分のコミットを別の土台（例：mainの最新）の上に積み直す処理で、コミットのハッシュ値が変わり**履歴が書き換わります**。このため、**すでにpushして他の人と共有しているブランチではrebaseを使わない**のが定番の注意です。

A. 送信しません。図解アニメの再生もコマンド一覧の表示もコピー機能も、すべてこのページを開いたブラウザの中だけで完結します。実際のgitコマンドやシェル、ネットワークには一切アクセスしません（送信ゼロ）。