Gitの基本コマンドまとめ｜clone・add・commit・pushを実務レベルで理解
Gitで日々の作業を回すなら、まず押さえるべき流れは clone → 作業 → add → commit → push です。リモートリポジトリを手元に複製し、変更内容を確認して、必要な差分だけを記録し、チームが見られる場所へ送ります。
この記事では、Gitを「なんとなくコマンドを打つ道具」ではなく、実務で事故を減らすための作業手順として整理します。対象は、GitHub、GitLab、Bitbucketなどのリモートリポジトリを使い始めた初学者から実務初級者です。
git cloneは、リモートリポジトリをローカルに複製するgit addは、次のコミットに入れる変更をステージングするgit commitは、ステージング済みの変更を履歴として記録するgit pushは、ローカルのコミットをリモートへ送る- 作業前後に
git statusとgit diffを挟むと、誤コミットや押し忘れを減らせる
ここがポイント: Gitの基本は「ファイルを保存する」ことではなく、「どの変更を、どの単位で、どこへ共有するか」を明確にすることです。
前提環境とこの記事で扱う範囲
この記事では、コマンドラインでGitを使う基本操作を扱います。
想定環境は次の通りです。
- Gitがインストール済み
- ターミナル、PowerShell、またはGit Bashを使える
- GitHubなどにリモートリポジトリがある
- ブランチ名は
mainを例にする
Gitの公式ドキュメントでは、各コマンドの最新版マニュアルが公開されています。2026年4月時点では、git commit や git status のマニュアルに Git 2.53.0 の更新情報が掲載されています。手元のバージョンは次のコマンドで確認できます。
git --version
出力例です。
git version 2.53.0
実務では、Gitの細かいバージョン差よりも、リモートの運用ルールや認証方式の違いのほうが詰まりやすいです。会社やチームで使う場合は、次の点も確認しておくと安全です。
- HTTPSとSSHのどちらで接続するか
main以外の既定ブランチ名を使っていないか- 直接
mainにpushできるか、Pull Requestが必須か - コミットメッセージの書式ルールがあるか
Gitの作業は4つの場所を行き来する
コマンドを覚える前に、Gitが見ている場所を押さえると理解しやすくなります。
Gitでは、変更がいきなりリモートに送られるわけではありません。手元のファイル、ステージングエリア、ローカルリポジトリ、リモートリポジトリを順に移動します。
| 場所 | 役割 | よく使うコマンド |
|---|---|---|
| 作業ツリー | 実際に編集しているファイル | git status, git diff |
| ステージングエリア | 次のコミットに入れる変更の置き場 | git add |
| ローカルリポジトリ | 自分のPC内にある履歴 | git commit, git log |
| リモートリポジトリ | チームやCIが参照する共有先 | git clone, git push, git pull |
この流れをコマンドで表すと、次のようになります。
リモートリポジトリ
↓ git clone
作業ツリーで編集
↓ git add
ステージングエリア
↓ git commit
ローカルリポジトリ
↓ git push
リモートリポジトリ
git add と git commit が分かれているのは、変更の一部だけを履歴に残せるようにするためです。たとえば、同じファイルを触っていても「ログ出力の追加」と「表示文言の修正」を別コミットにできます。
git clone：リモートリポジトリを手元に複製する
git clone は、既存のリモートリポジトリをローカルにコピーして、作業できる状態にするコマンドです。公式ドキュメントでも、リポジトリを新しいディレクトリへ複製し、リモート追跡ブランチを作るコマンドとして説明されています。
基本形は次の通りです。
git clone <リポジトリURL>
GitHubのHTTPS URLを例にします。
git clone https://github.com/example/sample-app.git
実行すると、通常はリポジトリ名と同じディレクトリが作られます。
cd sample-app
ディレクトリ名を指定してcloneする
ローカル側のフォルダ名を変えたい場合は、URLの後ろにディレクトリ名を指定します。
git clone https://github.com/example/sample-app.git my-app
cd my-app
実務では、検証用に同じリポジトリを別名でcloneしたい場面があります。そのときに便利です。
特定ブランチをcloneする
特定ブランチから作業を始めたい場合は -b を使います。
git clone -b develop https://github.com/example/sample-app.git
ただし、チーム開発ではclone後にブランチを確認してから作業するほうが安全です。
git branch
出力例です。
* main
git status：変更状況を確認する
git status は、Git作業の確認用コマンドです。何を編集したか、何がステージング済みか、まだGitが追跡していないファイルがあるかを表示します。
git status
編集直後の出力例です。
On branch main
Changes not staged for commit:
modified: README.md
Untracked files:
memo.txt
この例では、README.md は変更済みですが、まだ次のコミット対象には入っていません。memo.txt は新規ファイルで、Gitがまだ追跡していない状態です。
実務では、次のタイミングで git status を打つ習慣をつけるとミスが減ります。
- 作業を始める前
git addの前git commitの前git pushの前- エラーが出た直後
短く確認したい場合は -s を使います。
git status -s
出力例です。
M README.md
?? memo.txt
M は変更、?? は未追跡ファイルです。慣れてくると、通常表示よりこちらのほうが素早く確認できます。
git add：次のコミットに入れる変更を選ぶ
git add は、変更をステージングエリアに載せるコマンドです。公式ドキュメントでは、次のコミットに入れる内容を準備するために、作業ツリーの現在の内容でインデックスを更新するコマンドとして説明されています。
よく使う形は3つです。
git add README.md
git add src/
git add .
それぞれの意味は次の通りです。
git add README.md: 指定したファイルだけを追加するgit add src/: 指定したディレクトリ配下を追加するgit add .: 現在のディレクトリ配下の変更をまとめて追加する
実務で最初におすすめなのは、ファイル単位で明示してaddする方法です。git add . は便利ですが、不要なメモ、ログ、設定ファイルまで入れてしまうことがあります。
差分を見てからaddする
git add の前に git diff を使うと、まだステージングしていない変更を確認できます。
git diff
特定ファイルだけ見る場合です。
git diff README.md
変更内容を確認してからaddします。
git add README.md
ステージング済みの差分を確認するには、次のコマンドを使います。
git diff --staged
git diff と git diff --staged の違いは重要です。
git diff: まだステージングしていない差分を見るgit diff --staged: 次のコミットに入る差分を見る
一部の変更だけaddする
同じファイル内の一部だけコミットしたい場合は -p が使えます。
git add -p README.md
Gitが差分のまとまりごとに、ステージングするかどうかを聞いてきます。小さなコミットを作りたいときに便利ですが、最初は無理に使わなくても構いません。まずは「1つの目的に対して1つのコミット」を意識するだけで十分です。
git commit：変更を履歴として記録する
git commit は、ステージング済みの変更をローカルリポジトリの履歴に記録します。公式ドキュメントでは、リポジトリへ変更を記録するコマンドとして説明されています。
基本形です。
git commit -m "READMEにセットアップ手順を追加"
コミットメッセージは、あとから履歴を読む人のために書きます。実務では「何をしたか」だけでなく、「何のためにしたか」が分かるとレビューや障害調査で役立ちます。
悪い例です。
git commit -m "修正"
改善例です。
git commit -m "ログイン失敗時のエラーメッセージを修正"
さらに理由が必要なら、エディタで本文を書ける形式にします。
git commit
メッセージ例です。
ログイン失敗時のエラーメッセージを修正
認証エラーと通信エラーを同じ文言で表示していたため、
ユーザーが再入力すべきか待つべきか判断できなかった。
コミット前の確認手順
コミット直前は、次の順番で確認すると安全です。
git status
git diff --staged
git commit -m "変更内容が分かるメッセージ"
git status でステージング済みファイルを確認し、git diff --staged で実際に入る差分を見る。この2つを挟むだけで、不要ファイルの混入をかなり防げます。
コミット履歴を確認する
作成したコミットは git log で確認できます。
git log --oneline -5
出力例です。
8f3a2c1 READMEにセットアップ手順を追加
4b91d0e 初期構成を追加
--oneline は、履歴を短く見るための指定です。レビュー前やpush前の確認に向いています。
git push：ローカルのコミットをリモートへ送る
git push は、ローカルリポジトリにあるコミットをリモートリポジトリへ送るコマンドです。公式ドキュメントでは、ローカルリポジトリからリモートのブランチやタグなどの参照を更新し、必要なオブジェクトを送信するコマンドとして説明されています。
基本形です。
git push origin main
ここでの origin はリモート名、main はブランチ名です。git clone で取得したリポジトリでは、多くの場合リモート名として origin が設定されます。
リモート設定は次のコマンドで確認できます。
git remote -v
出力例です。
origin https://github.com/example/sample-app.git (fetch)
origin https://github.com/example/sample-app.git (push)
初回pushでupstreamを設定する
新しいブランチを作って初めてpushするときは、次の形をよく使います。
git push -u origin feature/add-login-message
-u は、現在のローカルブランチとリモートブランチの対応関係を設定します。以後は、同じブランチ上で次のように短くpushできるようになります。
git push
ただし、慣れるまでは git push origin ブランチ名 と明示するほうが、どこへ送るかを意識しやすいです。
push前にpullが必要なことがある
チームで同じブランチを触っていると、自分のローカルよりリモートのほうが進んでいる場合があります。その状態でpushすると、拒否されることがあります。
典型的な流れです。
git push origin main
出力例です。
! [rejected] main -> main (fetch first)
error: failed to push some refs
この場合は、リモートの変更を取り込んでから再度pushします。
git pull --rebase origin main
git push origin main
チームの運用によっては git pull の標準設定やrebase禁止のルールがあるため、職場ではプロジェクトのルールを優先してください。
実務でよく使う一連の流れ
ここでは、既存リポジトリをcloneして、READMEを修正し、リモートへpushする最小例を見ます。
1. リポジトリをcloneする
git clone https://github.com/example/sample-app.git
cd sample-app
2. 現在の状態を確認する
git status
出力例です。
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
この状態なら、作業を始めて問題ありません。
3. ファイルを編集する
例として README.md にセットアップ手順を追加したとします。
## Setup
```bash
npm install
npm run dev
### 4. 差分を確認する
```bash
git diff README.md
出力例です。
+## Setup
+
+```bash
+npm install
+npm run dev
+```
5. 変更をステージングする
git add README.md
ステージング後に確認します。
git status
出力例です。
Changes to be committed:
modified: README.md
6. コミットする
git commit -m "READMEにセットアップ手順を追加"
出力例です。
[main 8f3a2c1] READMEにセットアップ手順を追加
1 file changed, 5 insertions(+)
7. リモートへpushする
git push origin main
出力例です。
To https://github.com/example/sample-app.git
4b91d0e..8f3a2c1 main -> main
これで、ローカルのコミットがリモートリポジトリへ反映されます。
よくある失敗と直し方
Gitでつまずく原因の多くは、コマンドそのものではなく「今どの状態にいるか」を見失うことです。困ったら、まず git status を確認します。
addしたのにcommitされない
原因は、git add 後にさらにファイルを編集したケースが多いです。
git add README.md
# その後README.mdをさらに編集
git commit -m "READMEを更新"
この場合、最初にaddした時点の内容だけがコミットされます。追加編集分も入れるなら、もう一度addします。
git add README.md
git commit -m "READMEを更新"
間違って不要ファイルをaddした
ステージングを取り消すだけなら、作業ファイルは消さずに戻せます。
git restore --staged memo.txt
古い記事や環境では git reset HEAD memo.txt が紹介されていることもあります。どちらもステージング解除で使われますが、最近のGitでは目的が分かりやすい git restore --staged を見かける機会が増えています。
commitメッセージを直したい
直前のコミットメッセージだけを直すなら、次のコマンドを使います。
git commit --amend -m "READMEにセットアップ手順を追加"
ただし、すでにpush済みのコミットをamendすると、リモート履歴とのずれが発生します。共有済みコミットを直す場合は、チームの運用ルールを確認してください。
pushが拒否される
リモート側に自分のローカルにないコミットがあると、pushが拒否されることがあります。
! [rejected] main -> main (fetch first)
まず状態を確認します。
git status
次に、リモートの変更を取り込みます。
git pull --rebase origin main
競合がなければ、再度pushします。
git push origin main
競合が出た場合は、対象ファイルを開いて衝突箇所を解消し、git add、git rebase --continue の順で進めます。
実務で使うコマンドの使い分け
基本コマンドに慣れてきたら、確認系と補助系のコマンドもセットで覚えると作業が安定します。
| 目的 | コマンド | 使う場面 |
|---|---|---|
| 状態確認 | git status | 作業前、add前、commit前、push前 |
| 未ステージ差分の確認 | git diff | addする前に中身を見る |
| ステージ済み差分の確認 | git diff --staged | commitに入る内容を見る |
| 履歴確認 | git log --oneline | push前にコミットを確認する |
| リモート確認 | git remote -v | push先URLを確認する |
| ステージング解除 | git restore --staged ファイル名 | 間違ってaddしたとき |
特に git diff --staged は、初心者ほど後回しにしがちです。しかし実務では、commit前の最終確認としてかなり重要です。レビューに出す前に自分で差分を読む習慣があるだけで、不要な変更やデバッグコードの混入に気づきやすくなります。
セキュリティと認証情報の注意点
Gitでは、ソースコードだけでなく設定ファイルやログも簡単にコミットできます。便利な反面、認証情報を混ぜるとリモートへ公開される危険があります。
コミットしてはいけない代表例です。
- APIキー
- パスワード
- 秘密鍵
.envの本番用設定- 個人情報を含むCSVやログ
- 社内URLや顧客名が入った検証データ
除外したいファイルは .gitignore に書きます。
.env
*.log
node_modules/
dist/
ただし、.gitignore は「まだGitに追跡されていないファイル」を無視するための設定です。すでにコミット済みのファイルは、.gitignore に追加しても自動では履歴から消えません。
誤って秘密情報をpushした場合は、単にファイルを削除するだけでは不十分です。対象のキーやパスワードを無効化し、リポジトリ履歴からの削除が必要になることがあります。会社のリポジトリなら、すぐに管理者やセキュリティ担当へ連絡してください。
GUIツールやGitHub Desktopとの使い分け
Gitはコマンドラインだけでなく、GUIツールからも操作できます。
代表的な選択肢です。
- GitHub Desktop
- SourceTree
- Fork
- JetBrains IDEのGit機能
- Visual Studio Codeのソース管理機能
GUIは差分確認やブランチ切り替えが見やすく、初学者にも扱いやすいです。一方で、エラーが出たときは内部でどのGitコマンドが失敗しているかを理解しているほうが早く解決できます。
実務では、次の使い分けが現実的です。
- 普段の差分確認やコミットはGUIでもよい
- エラー調査やCI手順の再現はCLIを使えるようにする
- Pull Request前の最終確認では
git statusとgit logを見る - 強制pushや履歴変更は、GUIでもCLIでもチームルールを確認してから行う
CLIの基本を知っておくと、GUIを使う場合でも「今どの状態か」を説明できるようになります。
まず覚えるべき実務チェックリスト
最後に、日常作業で使う流れを短くまとめます。
git clone https://github.com/example/sample-app.git
cd sample-app
git status
# ファイルを編集
git diff
git add README.md
git diff --staged
git commit -m "READMEにセットアップ手順を追加"
git log --oneline -5
git push origin main
実務で見るべきポイントは、コマンドの暗記よりも次の3つです。
git addの前に、どのファイルを入れるか確認するgit commitの前に、ステージ済み差分を読むgit pushの前に、送るブランチとコミット履歴を見る
Gitの基本コマンドは少なく見えますが、操作の順番を間違えると不要ファイルの混入、履歴の乱れ、push拒否につながります。まずは status と diff を挟みながら、1つの目的ごとに小さくcommitするところから始めるのが実務では一番安定します。