技術入門 2026年4月9日

Git・GitHub入門：バージョン管理の基本をコードで理解する（2026年版）

エンジニア必須のGit/GitHubを、未経験から転職した筆者がコマンドの基礎から実務での使い方まで丁寧に解説。初めてでも迷わない入門ガイドです。

GitGitHubバージョン管理入門初心者

「Gitってなんとなく使ってるけど、実はよくわかってない」

これ、エンジニアになりたての頃の僕そのものです。git add . して git commit -m "修正" して git push する—操作はできていたんですが、「なぜそれをするか」を説明できませんでした。

結論から言うと、Gitはプログラミングと同じくらい重要なスキルです。エンジニアチームで働く限り、Git抜きの開発はほぼありえません。独学中の方も、転職活動の段階で「GitHubのリポジトリを見せてください」と言われます。

この記事では、Gitの概念から実務的な使い方まで、コードを交えて丁寧に解説します。

GitとGitHubのイメージ

筆者について

文系大学卒→営業3年→独学8ヶ月でWeb系企業に転職した元未経験エンジニアです。Git/GitHubを本格的に使いこなせるようになったのは、転職後の実務でした。「もっと早く体系的に学べばよかった」と思ったのがこの記事を書いた理由です。

GitとGitHubの違い

よく混同されるポイントから整理します。

	役割	使い方
Git	ローカルのバージョン管理ツール	PCにインストールして使う
GitHub	Gitのリモートホスティングサービス	Webサービス（アカウント登録）

コードで言うなら、Gitがあなたのパソコンの日記帳で、GitHubはその日記帳をクラウドに保存・共有するサービスです。

バージョン管理とは何か

Gitなし: report_final.docx → report_final2.docx → report_final_本当の最終.docx
Gitあり: 変更履歴が全て記録され、どの時点にも戻れる

正直、当時の僕はGitの必要性をなめていました。「個人で作るなら別にいらないじゃん」と。でも、初めてチームに入ったとき、Gitが使えないと仕事にならないことを痛感しました。

Gitのインストールと初期設定

インストール

Macの場合:

# Homebrewを使う場合
brew install git

# バージョン確認
git --version

Windowsの場合: git-scm.com からインストーラーをダウンロードします。インストール時の設定はデフォルトで基本的に問題ありません。

初期設定（最初に一度だけ）

# ユーザー名とメールアドレスを設定
git config --global user.name "中村ソウマ"
git config --global user.email "souma@example.com"

# デフォルトブランチ名をmainに設定（GitHub標準に合わせる）
git config --global init.defaultBranch main

# 設定確認
git config --list

ここがポイントなんですが、--global フラグは「このPC全体に設定する」という意味です。プロジェクトごとに変えたい場合は --global を外して実行します。

Gitの基本コマンド

リポジトリの作成から最初のコミットまで

# 新しいプロジェクトを作成
mkdir my-project && cd my-project

# Gitリポジトリを初期化
git init

# ファイルを作成
echo "# My Project" > README.md

# 変更をステージングに追加
git add README.md

# コミット（変更を記録）
git commit -m "first commit: README.mdを追加"

# 状態を確認
git status
git log --oneline

ここがポイントなんですが、「add（ステージング）→ commit（記録）」の2段階あるのがGitの特徴です。全ての変更を一度に記録するのではなく、「これだけをコミットしたい」と選択できるのが利点です。

よく使うコマンド一覧

# 変更状態を確認
git status

# 変更の差分を見る
git diff

# 全ての変更をステージング
git add .

# 特定のファイルだけステージング
git add src/App.js

# コミット
git commit -m "コミットメッセージを書く"

# コミット履歴を見る
git log
git log --oneline    # 1行で簡潔に

# 特定のコミットの変更内容を見る
git show コミットID

ブランチを使いこなす

ブランチとは

ブランチは「作業の分岐」です。新機能の開発やバグ修正を、メインのコードに影響を与えずに進められます。

main ─────────────────────────────→
         \                   /
          feature/login-page →

# 現在のブランチ確認
git branch

# 新しいブランチを作成して移動
git checkout -b feature/login-page

# (または最新の書き方)
git switch -c feature/login-page

# ブランチを移動
git switch main

# ブランチをマージ（mainに戻ってから）
git merge feature/login-page

# マージ済みのブランチを削除
git branch -d feature/login-page

正直、当時の僕はブランチを切らずに直接mainに作業していました。個人プロジェクトではなんとかなりますが、チーム開発では絶対にNGです。

GitHubとの連携

リモートリポジトリへのpush

GitHub上でリポジトリを作成した後、ローカルと紐づけます。

# リモートリポジトリを追加
git remote add origin https://github.com/yourname/my-project.git

# pushする（ローカル → GitHub）
git push -u origin main

# 以降は省略形でOK
git push

pullとfetch

チーム開発では、他の人が加えた変更をローカルに取り込む必要があります。

# リモートの変更をローカルに取り込む（fetch + merge）
git pull

# 変更内容を確認してからマージしたい場合
git fetch
git diff origin/main    # リモートとの差分確認
git merge origin/main

チーム開発のワークフロー

プルリクエスト（PR）の流れ

プルリクエストとは

GitHubのプルリクエスト（Pull Request）は、「このブランチの変更をmainにマージしてください」という申請です。チーム開発では、コードレビューの主な場所になります。

# 新しいブランチで作業
git switch -c feature/add-user-form

# 変更してコミット
git add .
git commit -m "ユーザー登録フォームを追加"

# GitHubにpush
git push origin feature/add-user-form

この後、GitHub上でプルリクエストを作成します。チームメンバーがレビューしてOKなら、mainにマージされます。コードレビューのベストプラクティスについてはコードレビューを効率化する方法2026年版も参考にしてみてください。

よくあるトラブルと対処法

コンフリクト（競合）の解決

チーム開発で同じファイルを複数人が変更すると「コンフリクト」が起きます。

<<<<<<< HEAD
const greeting = "こんにちは";  // 自分の変更
=======
const greeting = "Hello";        // 相手の変更
>>>>>>> feature/english-greeting

どちらの変更を採用するか（または両方組み合わせるか）を手動で決め、<<< や >>> の記号を消してから再コミットすることで解決します。

コミットを取り消したい

# 直前のコミットを取り消す（変更はステージングに残す）
git reset --soft HEAD~1

# 直前のコミットを取り消す（変更も元に戻す）
git reset --hard HEAD~1

# 特定のファイルの変更を取り消す
git restore ファイル名

.gitignoreで不要なファイルを除外

# .gitignoreを作成
touch .gitignore

# .gitignore の中身（例）
node_modules/
.env
.DS_Store
dist/
*.log

node_modules は絶対にgitに含めてはいけません。これを知らずにpushして何百MBものリポジトリにしてしまうのは、未経験エンジニアの定番ミスです。

Gitを使いこなすための次のステップ

Gitの基礎を覚えたら、次に取り組むと良いことをまとめます。

GitHub Copilotを活用する: AIがコードを補完してくれるツール → GitHub Copilot活用術
ポートフォリオをGitHubで公開する: 転職活動での必須要素 → ポートフォリオの作り方
独学ロードマップを確認する: 次に何を学ぶべきか → 独学プログラミングのロードマップ

まとめ

大事なのは「Gitはツールではなく、エンジニアの共通言語だ」という認識です。

コードが書けてもGitが使えないと、チームでは「使えないエンジニア」になります。逆に言えば、Gitを使いこなせると「この人は実務をわかっている」という印象を与えられます。

まずは今日の内容を手元で動かして、GitHubに最初のpushをしてみてください。それだけで「GitHubに草が生える」状態になります。これは断言できます。

GitHubのコントリビューション

独学に限界を感じたら:

GitやGitHubの使い方は、「実際に使ってみないとわからない」部分が多いです。コンフリクトの解消など、一人だと詰まりやすい場面があります。

もし独学の限界を感じたら、プログラミングスクールという選択肢を検討してみてください。現役エンジニアのメンタリングがある環境では、こういったギモンを即解決できます。

→ プログラミングスクール比較2026年版

Colosoでプロから学ぶ

業界トップの講師によるオンライン講座。買い切り型で何度でも復習可能。

Colosoを見る →