実務で使うGitコマンド集

Gitはコマンドが多く、最初は「どれをいつ使うのか」が分かりにくいツールです。この記事では暗記用の一覧ではなく、作業の場面ごとに「ここではこれを使う」という形でまとめました。コピペして使えるよう、実際のコマンド例も載せています。

まずは作業の入り口。新規に作るか、既存のものを複製するかで分かれます。

# いまのフォルダを新しいGitリポジトリにする
git init

# リモートのリポジトリを丸ごと複製する
git clone https://github.com/user/repo.git

# 既存のローカルリポジトリにリモートを後付けする
git remote add origin https://github.com/user/repo.git

# 登録済みのリモートを確認する
git remote -v

# 最初のpushでブランチを紐付ける（mainの場合）
git push -u origin main

git init は「ここをGit管理下にする」宣言、git clone は「他人／自分のリポジトリを手元に持ってくる」操作です。git remote add は、先にローカルで作ってしまったプロジェクトを後からGitHubに接続したいときに使います。

Gitの基本サイクルは「変更を確認 → ステージング → コミット」です。

# いま何が変わっているかを確認
git status

# 変更内容（差分）を見る
git diff

# 変更をステージング（コミット候補に上げる）
git add ファイル名
git add .            # すべての変更をまとめて

# 記録（コミット）する
git commit -m "変更内容の説明"

# add と commit をまとめて（追跡済みファイルのみ）
git commit -am "メッセージ"

# 履歴を見る
git log
git log --oneline    # 1行ずつ簡潔に

コミットメッセージは「何を・なぜ変えたか」が後から分かるように書くのがコツです。git diff でコミット前に内容を見直す習慣をつけると、不要なファイルの混入を防げます。

機能ごとに作業を分けるのがブランチです。最近は switch が分かりやすく推奨されます。

# ブランチ一覧
git branch

# 新しいブランチを作って移動する
git switch -c feature/login
# （従来の書き方： git checkout -b feature/login）

# 既存のブランチに移動する
git switch main

# ブランチをmainに取り込む（mainに移動してから）
git switch main
git merge feature/login

# いらなくなったブランチを削除
git branch -d feature/login

switch は「ブランチの移動」、checkout は移動とファイル復元の両方を兼ねる古い万能コマンドです。混乱しやすいので、ブランチ操作は switch、ファイルの復元は次に出てくる restore と使い分けると整理されます。

# リモートの最新を取得（手元には反映しない）
git fetch

# リモートの最新を取得して、いまのブランチに反映
git pull

# 手元のコミットをリモートへ送る
git push

fetch は「情報だけ取ってくる（安全）」、pull は「取ってきて即マージする」という違いです。チームで作業しているときは、push の前に pull して最新を取り込んでおくと、コンフリクトを早めに片付けられます。

コンフリクトは、同じ場所を別々の人（またはブランチ）が違う内容に変えたときに起きます。Gitが自動でどちらを採用すべきか判断できず、人間に委ねてくる状態です。怖がる必要はなく、手順は決まっています。

マージやプル時に衝突すると、ファイル内に次のようなマーカーが入ります。

<<<<<<< HEAD
いまのブランチの内容
=======
取り込もうとしている側の内容
>>>>>>> feature/login

解決の手順はこうです。

• <<<<<<< HEAD 〜 ======= が「自分側」、======= 〜 >>>>>>> が「相手側」
• どちらを残すか（あるいは両方を組み合わせるか）を決め、マーカー行も含めて手で書き直す
• 直したファイルを git add して、git commit で確定する

# どのファイルが衝突しているか確認
git status

# 中身を直したらステージング
git add 直したファイル

# マージを完了させる
git commit

# やっぱりやめて元に戻したいとき
git merge --abort

「ぐちゃぐちゃになって分からなくなった」ときは、git merge --abort でマージ前の状態に戻せます。落ち着いてやり直せるので、焦って変なコミットを作るより安全です。

Gitは「やらかしても戻せる」のが強みです。場面によって使う取り消しが違います。

# 作業中の変更を捨てて元に戻す（コミット前）
git restore ファイル名

# ステージングだけ取り消す（変更は残す）
git restore --staged ファイル名

# 直前のコミットメッセージを修正する
git commit --amend -m "新しいメッセージ"

# 直前のコミットを取り消す（変更は手元に残す）
git reset --soft HEAD~1

# あるコミットを「打ち消す」新しいコミットを作る（公開済み向け）
git revert コミットID

ポイントは、まだ公開（push）していない変更は reset で巻き戻してOKですが、すでに共有済みの履歴は revert で「打ち消しコミット」を足すほうが安全、ということです。共有済みの履歴を reset で書き換えると、他の人の手元と食い違ってトラブルになります。

知っていると作業が一段ラクになる、出番の多いものをまとめました。

# 作業を一時退避する（中断して別ブランチに移りたいとき）
git stash
git stash pop          # 退避した変更を戻す

# 履歴を枝分かれ込みで見やすく表示
git log --oneline --graph --all

# 特定のコミットだけ別ブランチに持ってくる
git cherry-pick コミットID

# ファイルが「いつ・誰に」変えられたか追う
git blame ファイル名

# 追跡したくないファイルを無視する（.gitignore に書く）
# 例： node_modules/  .env  *.log

# 一度コミットしたファイルを追跡から外す（ファイルは残す）
git rm --cached ファイル名

特に git stash は、「急ぎで別のブランチを直したいけど、いまの作業はまだコミットしたくない」という場面で重宝します。.gitignore は早めに整えておくと、.env のような秘密情報やビルド成果物を誤ってコミットする事故を防げます。

Gitは「作る → 記録する → 分岐する → 同期する → 直す」という流れで考えると、どのコマンドがどの場面のものか整理しやすくなります。コンフリクトもマーカーの読み方さえ分かれば怖くありません。全部を暗記する必要はないので、この記事をブックマークして、迷ったときに場面から引いてもらえれば十分です。