【Git】git checkout とは？使い方を初心者向けにわかりやすく解説
はじめに
皆さんは、Git を使ってソースコードを管理したいと思ったことはありませんか。 Git はファイルの変更履歴を追跡できるため、開発の効率を大きく高める手段としてよく利用されています。 その中でも git checkout は、ブランチやコミットを切り替える操作に関して欠かせないコマンドです。
ただし、初めて Git に触れるときには「git checkout は具体的に何をするものだろう？」と疑問を感じるかもしれません。 また、実際に使う中で「過去のコミットに戻ってコードを確認したい」といったケースも出てきます。 そんなときに役立つのが、本記事で解説する git checkout です。
ここではコマンドの概要から具体的な使い方、実務での活用ポイントまでを初心者の方にもわかりやすくまとめました。 バージョン管理に興味を持ったばかりの方や、これからチーム開発に携わりたい方にとって、有益な情報をお伝えできれば幸いです。
この記事を読むとわかること
- git checkout の基本的な役割と意味
- ブランチを切り替えるときの手順や注意点
- 過去のコミットに戻る操作の具体例
- 実務の現場でチェックアウトを使う活用シーン
- よくある疑問点やトラブル事例と対策方法
git checkout とは？
git checkout は、Git で管理しているコードの状態を「別のブランチ」や「特定のコミット」などに切り替えるためのコマンドです。 一言でいうと、作業対象を別の状態に移動させる機能を果たします。
たとえば、現在 main ブランチで作業している場合に、別のブランチ feature-A に移動したいときに git checkout feature-A を使います。
また、過去にコミットした履歴を調べたいときには、コミットIDを指定して git checkout コミットID のようにすることで、そのコミットが行われた時点のファイル内容に切り替え可能です。
git checkout の実務イメージ
実務では、開発を進めている途中で別の作業を優先したいときや、過去に行った修正を参照したいときに git checkout が役に立ちます。 例えば「新しい機能追加ブランチを作る前に、バグ修正のブランチへ移動してすぐに修正を行う」といった流れをスムーズに行えます。 そのため、ブランチ管理を快適にするためには必須の操作といえるでしょう。
ブランチを切り替えるときの使い方
ブランチを切り替える操作は、バージョン管理をする上で最もよく使われます。 新しい機能を開発するときに別ブランチを作成する、テストをするときに特定のブランチに移動するなど、日常的な作業の要となります。
基本的なブランチ切り替え手順
ブランチを切り替えるには、以下のようなステップを意識します。
1. 現在の作業内容をコミットまたはスタッシュしておく
切り替え前に未コミットの変更がある場合、作業が中途半端に上書きされることがあるためです。
まずは git add . → git commit -m "WIP" のようにコミットするか、git stash で変更を一時退避します。
2. git checkout を使って、切り替えたいブランチ名を指定する
例：git checkout develop
3. 必要に応じてコミットやスタッシュした内容を反映させる
スタッシュを使用した場合は git stash pop で取り出します。
実際の手順は下記のコード例のようになります。
# まず現在の変更をコミットする git add . git commit -m "一時的なコミット" # develop ブランチに切り替える git checkout develop # ここから先は、新たにファイルを編集し、別の作業を始めることが可能になる
ブランチを新規作成して切り替える方法
既存のブランチではなく、新たにブランチを作成した上で切り替えるシーンも多いです。 その場合は次のような操作を行います。
# 新規ブランチ feature-A を作成し、同時に切り替え git checkout -b feature-A # ここから feature-A ブランチでコードを書き始められる
-b オプションを付けることで、指定したブランチが存在しない場合は作成し、同時にそこへ移動します。
これは「素早くブランチを作成して別作業に取りかかる」場面でよく用いられます。
コミットをチェックアウトする使い方
ブランチを切り替えるだけでなく、特定のコミットへ移動したい場合にも git checkout は便利です。 過去のバージョンに戻って「正しく動いていた頃のコード」を参照するといったときには強い味方になってくれます。
過去のコミットに切り替えたい場合
まず git log で履歴を表示し、切り替えたいコミットのハッシュ（ID）を確認します。
その後、以下のようにコミットIDを指定してチェックアウトします。
git checkout 123abc456def
この操作により、作業ツリーが指定したコミットの時点の状態に切り替わります。 ただし、この状態は「過去のバージョンを閲覧しているだけ」なので、別のブランチへ移動するまでは Detached HEAD という状態になる点には注意しましょう。
間違った変更を取り消したい場合
チーム開発や長期開発では、何らかのミスがあり「特定のコミットをなかったことにしたい」というケースもありえます。
単純に「過去のコミットの状態に戻して作業をやり直す」のであれば、git checkout <コミットID> で過去に戻ったうえで、新しいブランチを作成するというやり方があります。
一例としては下記のような流れです。
# 過去のコミットにチェックアウト git checkout 123abc456def # 新たにブランチを作成し、そこに状態を引き継ぐ git checkout -b revert-feature # revert-feature ブランチで修正や再度の変更を行う
こうすることで、既存の作業には影響を与えずに「過去の状態からやり直す」ことが可能です。 誤ったコミットの内容を参照しながら、再度正しい手順で修正を加えていくという流れになります。
git switch との違い
Git のバージョンが進むにつれ、ブランチの切り替えには git switch コマンドが推奨される場面が増えています。 git checkout は本来「ブランチ・コミットを切り替える」「ファイルの変更を破棄する」の二つの機能を持ち合わせていました。 しかし、機能が複数あるため初学者が混乱することも多かったのです。
一方 git switch は「ブランチを切り替える」機能に特化しています。
たとえば git switch develop とすれば、ただちに develop ブランチへ移動できます。
また git switch -c feature-B とすることで、ブランチの新規作成も一度に行えます。
ファイルの変更を破棄したいときは、git restore コマンドが別途用意されています。
しかし、まだまだ git checkout が一般的に使われることも事実です。 たとえば各種ドキュメントやチュートリアルの中で、git checkout が標準的な操作として紹介されているケースも多く、現場によってはgit checkout をメインに使っている場合もあります。 したがって、最初に学ぶ段階では git checkout の動きを理解することは大切です。
実務での活用ポイント
では、実際の開発現場では git checkout をどのように活用するのでしょうか。 ここではブランチ管理や不具合修正など、よくあるシーンを取り上げてみます。
チーム開発におけるブランチ管理
チームで作業するとき、メンバーごとに違う機能を同時に開発する場面が多々あります。
このとき、個々の開発者が独立したブランチを切り、作業が終わった段階で main や develop ブランチに統合するスタイルが一般的です。
例えば「ユーザー認証機能のブランチ」「商品検索機能のブランチ」「管理画面の UI 調整用ブランチ」などが同時進行するようなイメージです。 それぞれ機能ごとのブランチを行き来しながら動作確認やレビューを行うため、git checkout は頻繁に使用されます。 上手に使いこなすことで、衝突（コンフリクト）を最小限に抑えながら効率的に開発できるでしょう。
リリース前の検証や不具合修正
リリース前には「テスト専用のブランチ」を作り、最新のソースコードを集約するケースがあります。 また、不具合が見つかった場合にも「不具合修正ブランチ」を用意して対応することが多いです。 リリース直前に別ブランチでテストし、問題がなければ本番環境へ反映する、という流れですね。
このような複数ブランチ間での往来が必要な場面では、以下のようなフローがよく見られます。
# 不具合修正ブランチへ移動 git checkout bugfix-login-issue # 修正を終えたらコミット git add . git commit -m "ログイン不具合修正" # テスト用ブランチへ移動して動作確認 git checkout test-release
ブランチを切り替えながら動作確認を繰り返すことで、「本当に修正がうまく機能しているのか」を検証できます。 このように git checkout は、日々のコードレビューや検証作業など、幅広い場面で利用されます。
ブランチを切り替える際に未コミットの変更があると、その内容が上書きされたり失われたりする可能性があります。 十分に気をつけながら、必要に応じて作業内容をコミットまたはスタッシュしましょう。
よくある質問と注意点
ここからは、git checkout を使うときに初心者がよく感じる疑問点や、気をつけるべきトラブルについてまとめます。 これらを知っておくと、混乱を減らしてスムーズにバージョン管理を進められます。
git checkout で作業が消えることはある？
作業が「消えてしまう」という誤解が生じやすいポイントとしては、未コミットの変更 を放置したまま別ブランチに移動したり、特定のコミットをチェックアウトしたりするケースが挙げられます。 未コミットの変更はブランチを超えて引き継がれないことも多いため、「編集中だったファイルが元に戻ってしまった」と驚く人が少なくありません。
対策としては、以下を意識しましょう。
- 作業が終わったらこまめにコミットする
- 途中でブランチを切り替えたい場合は
git stashで変更を一時退避しておく
これだけで、大半のトラブルを防止できます。
使い方を誤るとどうなる？
git checkout の使い方を誤ると、以下のような問題が起こりがちです。
- デタッチド HEAD 状態 で操作を続けてしまい、作業内容が不明瞭になる
- 本来は別のブランチで作業すべき内容を、誤って
mainブランチ上で行ってしまう - 不要なコミットが積み重なり、履歴が複雑化する
いずれも、どのブランチにいるのかを確認せず作業すると起こりやすいトラブルです。
git branch --show-current などで、今のブランチを常に把握しながら開発するのがポイントです。
まとめ
git checkout は、ブランチやコミットを自由に行き来するための基本コマンドです。 ただブランチを切り替えるだけでなく、過去のコミットに戻ってコードを確認したり、テストや不具合修正に対応したりと、幅広いシーンで役立ちます。
一方で、ブランチの切り替えにあたって作業内容をコミットしていないと、変更が思わぬ形で上書きされる可能性もあります。 したがって、「こまめにコミットする」「ブランチを適切に使い分ける」という基本を習得しておくことが大切です。
開発が進むにつれて、より洗練されたワークフローを確立したいと感じることも出てくるでしょう。 その一歩目として、git checkout の正しい使い方を身につけて、日々の開発やチーム作業をスムーズに進めてみてください。