【Git入門】コマンドライン操作の基礎！初心者でも迷わない基本のGitコマンド10選
やあ、君！新しい開発の世界に飛び込もうとしているんだね。素晴らしい！
君がこれから触れるであろう、数々の新しいツールやIDE、フレームワーク。どれもワクワクするけれど、その土台となるのが「バージョン管理システム」、中でもデファクトスタンダードである「Git」なんだ。
「Gitって難しそう…」って思ってるかもしれないけど、心配いらないよ。今日は、君が最初に必ず通る道、コマンドラインでのGitの基本を、まるで魔法のようにスルスルと理解できるよう、優しく丁寧に解説していくからね。これをマスターすれば、毎日の作業が劇的に楽になるだけでなく、チーム開発でのミスも減り、君のエンジニアとしての信頼度もグッと上がるはずさ。
さあ、一緒にGitの世界への扉を開けてみよう！
1. Gitって、そもそも何者？ ～バージョン管理システムの役割～
まずは、Gitが何をするものなのか、その本質を理解しよう。
Gitは、君のコードの「時間旅行マシン」だ！
開発を進めていると、どうしても「あの時のコードに戻りたい」「この変更を入れる前の状態はどうだったっけ？」なんて状況に必ず出くわす。Gitは、そんな時に君のコードの変更履歴をすべて記録しておいてくれるんだ。
- 変更履歴の管理: いつ、誰が、どんなコードを、なぜ変更したのか、そのすべてを記録できる。
- 過去への復帰: 間違った変更をしてしまっても、簡単に以前の状態に戻せる。
- 複数人での共同開発: チームメンバーがそれぞれ作業したコードを、衝突なく一つにまとめることができる。
まるで、君が書いた物語の「変更履歴」をすべて保存しておいてくれて、いつでも好きな時点の物語を読み返したり、過去のバージョンと今のバージョンを比較したりできる、そんなイメージかな。
2. Gitを君の手に！ ～インストールと初期設定～
まずは、Gitを君のPCに迎え入れよう。
2.1. Gitのインストール
お使いのOSによってインストール方法は少し違うけれど、基本は簡単。
- Windows: [Git for Windows](https://gitforwindows.org/) からインストーラーをダウンロードして、画面の指示に従ってインストールしよう。途中、いくつか選択肢が出てくるけど、基本的にはデフォルトのままでOK。
- macOS:
- Homebrewを使っているなら、ターミナルで `brew install git` と打つだけ。
- Homebrewを使っていない場合でも、Gitリポジトリを初めて操作しようとした時に、Xcode Command Line Toolsのインストールを促されることがあるので、その指示に従ってインストールすればOK。
- Linux (Debian/Ubuntu系): ターミナルで `sudo apt update && sudo apt install git` と打つ。
インストールが完了したら、ターミナル（WindowsならGit Bashやコマンドプロンプト、macOS/Linuxならターミナル）を開いて、以下のコマンドを実行してみよう。
git –version
これで、インストールされているGitのバージョンが表示されれば成功だ！
2.2. 初期設定 ～君の名前とメールアドレスを世界に刻む～
Gitは、誰がいつコードを変更したのかを記録するために、君の名前とメールアドレスを必要とする。これは、後で履歴を見たときに「誰がやったんだろう？」と迷わないための、とっても大事な情報なんだ。
ターミナルで、以下のコマンドを実行して、君の名前とメールアドレスを設定しよう。
自分の名前に置き換えてね！
git config –global user.name “君の名前”
普段使っているメールアドレスに置き換えてね！
GitHubなどのサービスで使うメールアドレスと一致させると便利だよ。
git config –global user.email “your_email@example.com”
`–global` オプションをつけることで、この設定が君のPC全体で有効になる。一度設定すればOKだよ。
設定が正しくできているか確認するには、以下のコマンドを実行してみよう。
git config –global user.name
git config –global user.email
ちゃんと君の名前とメールアドレスが表示されるはずさ。
3. Gitの基本サイクル ～clone, add, commit, push, pull～
ここからが本番！Gitの最も基本的な、そして最も頻繁に使うコマンドサイクルを、図解しながら見ていこう。
3.1. リモートリポジトリとローカルリポジトリ
まずは、この二つの関係性を理解しよう。
- リモートリポジトリ (Remote Repository): GitHubやGitLabなどのオンラインサービスで管理されている、共有用のリポジトリ。チームメンバーとコードを共有したり、バックアップとして使ったりする。
- ローカルリポジトリ (Local Repository): 君のPC上に作成される、開発作業を行うためのリポジトリ。リモートリポジトリのコピーとも言える。
基本的には、「ローカルリポジトリで作業 → リモートリポジトリに反映」「リモートリポジトリの更新をローカルリポジトリに取り込む」という流れで作業を進めるんだ。
3.2. 最初のステップ：リモートリポジトリを「clone」してくる
君が開発を始めるとき、多くの場合、既にリモートリポジトリが存在する。まずは、それを君のPCに「コピー」してくることから始めるんだ。この作業を「クローン (clone)」と呼ぶ。
例: GitHubにあるリポジトリをクローンする場合
git clone https://github.com/username/repository-name.git
このコマンドを実行すると、指定したURLのリポジトリが、`repository-name` という名前のフォルダとして君のPCに作成される。そのフォルダの中には、リモートリポジトリのすべてのファイルと、過去の変更履歴（コミット履歴）がまるっとコピーされているんだ。
graph LR
A[リモートリポジトリ (GitHub)] — clone –> B(ローカルリポジトリ
(君のPC));
3.3. コードを「変更」したら、「add」して「commit」！
さて、クローンしてきたリポジトリのフォルダに入って、コードを編集してみよう。例えば、`README.md` ファイルに君の名前を追加したとしよう。
Gitは、君が「どのファイルを変更したのか」を把握しておきたい。そして、「いつ」「どんな変更を」「なぜ」行ったのかを記録したい。
1. 変更内容の「ステージング」 (add)
変更したファイルを、コミットの「候補」として一時的に預かる場所（ステージングエリア）に移動させる。
# 変更されたファイルすべてをステージングする場合
git add .
# 特定のファイルをステージングする場合
git add README.md
`.` は「現在のディレクトリにあるすべての変更」を意味する。
2. 変更内容の「記録」 (commit)
ステージングされた変更を、君のローカルリポジトリに「コミット」として記録する。この時、変更内容を説明するメッセージを必ず添えよう！ このメッセージが、未来の君やチームメンバーにとって、変更の意図を理解する手がかりになるんだ。
git commit -m “Add my name to README”
`-m` オプションで、コミットメッセージを直接指定できる。
【現場の知恵】
コミットメッセージは、簡潔かつ具体的に書くのが鉄則！「修正」「変更」のような曖昧なメッセージはNG。「Fix: User login bug」「Feat: Add new user profile page」のように、何をしたのかが一目でわかるように工夫しよう。GitHubなどで使われるConventional Commitsの規約を参考にすると、チーム開発でさらに威力を発揮するよ。
graph LR
A[君のコード (Working Directory)] — git add –> B(ステージングエリア
(Staging Area));
B — git commit –> C(ローカルリポジトリ
(Local Repository));
C — 変更履歴 –> C;
3.4. ローカルの変更を「push」して、みんなと共有！
君がローカルリポジトリで作業した変更は、まだ君のPCの中にしかない。これを、オンラインにあるリモートリポジトリに「送る」作業が「プッシュ (push)」だ。
git push origin main
- `origin`: リモートリポジトリの名前（通常、`git clone` すると自動で設定される）。
- `main`: プッシュしたいブランチの名前（最近は `main` がデフォルトになっていることが多い。以前は `master` だった）。
このコマンドで、君がローカルでコミットした変更が、リモートリポジトリに反映される。これで、チームメンバーも君の最新の変更を見ることができるようになるんだ。
graph LR
A(ローカルリポジトリ
(Local Repository)) — git push –> B[リモートリポジトリ (GitHub)];
3.5. 他の人の変更を「pull」して、最新の状態に！
チームで開発していると、君が作業している間に、他のメンバーがリモートリポジトリに変更をプッシュしているかもしれない。君のローカルリポジトリを常に最新の状態に保つために、「プル (pull)」コマンドを使う。
git pull origin main
これは、「リモートリポジトリ (origin) の `main` ブランチにある最新の変更を、君のローカルリポジトリに持ってきて、マージ（統合）してね」という意味。
graph LR
A[リモートリポジトリ (GitHub)] — git pull –> B(ローカルリポジトリ
(Local Repository));
【基本サイクルまとめ】
1. `git clone`: リモートリポジトリをローカルにコピーする。
2. コードを編集: ファイルを変更したり、新しく作ったりする。
3. `git add`: 変更したファイルをコミットの候補としてステージングする。
4. `git commit`: ステージングされた変更を、メッセージと共にローカルリポジトリに記録する。
5. `git push`: ローカルリポジトリの変更をリモートリポジトリに反映させる。
6. `git pull`: リモートリポジトリの最新の変更をローカルリポジトリに取り込む。
この5つのコマンド（`add` と `commit` をセットで考えると6つかな）が、Gitの血液循環のようなもの。これを理解し、使いこなせるようになれば、君の開発効率は格段に上がるよ！
4. 最初のコミットまで、やってみよう！
言葉だけじゃイメージしにくいよね。実際に、簡単なプロジェクトで最初のコミットまでをやってみよう。
4.1. 準備：ローカルリポジトリを作る
まずは、君のPC上に新しくGitリポジトリを作ってみよう。
1. ターミナルを開き、適当な場所に新しいフォルダを作成して、そのフォルダに移動する。
mkdir my-first-git-project
cd my-first-git-project
2. このフォルダをGitリポジトリとして初期化する。
git init
これを実行すると、`my-first-git-project` フォルダの中に `.git` という隠しフォルダが作成される。これがGitの管理情報がすべて詰まっている場所なんだ。
4.2. ファイルを作成して、最初のコミット！
1. 簡単なテキストファイル (`hello.txt`) を作成してみよう。
echo “Hello, Git!” > hello.txt
2. 現在のリポジトリの状態を確認してみよう。
git status
`Untracked files:` という項目に `hello.txt` が表示されているはずだ。これは、「Gitが管理していない新しいファイルだよ」ということを教えてくれている。
3. この `hello.txt` をコミットの候補にする。
git add hello.txt
もう一度 `git status` を実行してみよう。今度は `Changes to be committed:` という項目に `hello.txt` が表示されているはずだ。ステージングされた状態になったんだね。
4. ステージングされた `hello.txt` をコミットする。
git commit -m “Initial commit: Add hello.txt file”
これで、君のローカルリポジトリに最初のコミットが記録された！
5. コミット履歴を確認してみよう。
git log
君が先ほど入力したコミットメッセージと、コミットした日時、コミットした人の情報が表示されるはずだ。
これで、君はGitリポジトリを作成し、ファイルを追加して、最初のコミットを完了できた！おめでとう！
5. さらに進むための、いくつかのコマンド
基本サイクル以外にも、知っておくと便利なコマンドがいくつかある。
5.1. 変更履歴を詳しく見る (`git log`)
`git log` は、コミット履歴を見るためのコマンドだけど、オプションも豊富なんだ。
- 一行で表示:
git log –oneline
コミットIDの短縮形とコミットメッセージだけが表示され、見やすくなる。
- ツリー構造で表示:
git log –graph –oneline –all
ブランチの合流などが視覚的にわかりやすくなる。チーム開発でブランチをたくさん使うようになったら、これは必須だよ。
5.2. 変更差分を確認する (`git diff`)
コミットする前に、ファイルにどんな変更を加えたのかを確認したいときがあるよね。
- ステージング前の差分:
git diff
まだ `git add` していない、作業中の変更（Working Directory）とステージングエリア（Staging Area）の差分を表示する。
- ステージング後の差分:
git diff –staged
# または
git diff –cached
ステージングエリア（Staging Area）と、最後にコミットした状態（HEAD）との差分を表示する。コミット前に「本当にこれでいいかな？」と確認するのに使う。
5.3. リモートリポジトリの情報を確認する (`git remote`)
`git clone` すると、通常 `origin` という名前でリモートリポジトリが登録される。その情報を確認するには、以下のコマンドを使う。
git remote -v
`fetch`（取得）と `push`（送信）のURLが表示される。
6. まとめ：君の「開発体験」を変える第一歩
どうだったかな？
最初は少し戸惑うかもしれないけれど、今回紹介したコマンド（`clone`, `add`, `commit`, `push`, `pull`、そして `status`, `log`, `diff`）は、Gitを使う上での「挨拶」や「自己紹介」のようなもの。これらをマスターすれば、君はもうGitの基本を理解したと言える。
「バージョン管理」という、開発者なら誰もが避けては通れない、でも少し敷居が高いと思われがちな分野の、最も重要な入り口を君は突破したんだ。
この基本をしっかりと身につけることで、
- 安心してコードを書けるようになる:「間違えても大丈夫」という安心感は、創造性を解き放ってくれる。
- チームとの連携がスムーズになる: コードの共有やレビューが、驚くほど効率的になる。
- 「なぜ」変更したのかを意識するようになる: コミットメッセージを書くたびに、自分のコードの意図を再確認する習慣がつく。
これから君は、さらにブランチを切って複数の機能を並行開発したり、他の人のコードをレビューしたり、もっと高度なGitのテクニックを学んでいくことになるだろう。でも、そのすべては今日学んだ基本の上に成り立っている。
焦らず、一つずつ、君のペースでGitと仲良くなっていってほしい。
もし途中で迷ったら、いつでもこのブログを思い出して、基本に立ち戻ってみてくれ。
君の素晴らしい開発ライフを、心から応援しているよ！