gitとGitHubの違いは？

gitは自分のPCの中で変更履歴（セーブ）を取る道具でネットは要らない。GitHubはそのセーブをネット上に置いて共有・公開・バックアップする場所。ゲームで言うとgitがセーブ機能、GitHubがクラウドセーブにあたる。

初心者はまずどのgitコマンドを覚えればいい？

毎日使うのは status（状態を見る）→ add（変更を載せる）→ commit（保存する）→ push（GitHubに上げる）、そして作業前の pull（最新を取り込む）。この5語のループがgitの心臓部で、実務の大半はこれで回る。

秘密情報（.envやAPIキー）を間違えてGitHubに上げたら？

「消せば大丈夫」ではない。gitは履歴を保持し、公開リポジトリなら数分で悪用されうるので、上げた瞬間に流出したと考える。唯一の正解は、該当するキーやトークンを無効化して作り直すこと。最初に.gitignoreで除外しておくのが一番の予防。

git／GitHub入門【2026】コピペで動く最短ルート（初心者・学生向け）

目次 / INDEX

プログラミングを続けるなら、gitとGitHubはどこかで必ず通る道だ。課題でも、個人開発でも、「バージョン管理くらいできて当たり前」の空気がある。でも最初は用語が難しくて身構えがちなので、この記事では専門用語を最小限にして、コピペで1周できる形でまとめる。コマンドには全部「なぜそうするか」を付けた。

結論 gitは自分のPCで履歴を取る道具、GitHubはそれをネットで共有する場所。覚えることの核は5つだけ。statusで見て → addで載せて → commitで保存して → pushで共有。始める前にpull。まずこのループが回れば十分で、ブランチや細かい機能は後からでいい。

まず結論：gitとGitHubは別モノ

一言で言うと、

git … 自分のPCの中で「セーブ（履歴）」を取る道具。ネットは要らない。
GitHub … そのセーブをネット上に置いて、共有・公開・バックアップする場所。

ゲームで例えると、gitがセーブ機能、GitHubがクラウドセーブ。gitだけでも完結するけど、PCが壊れたら終わり。GitHubにpushして初めて「どこからでも取り出せる／人に見せられる」状態になる。この記事は「gitで履歴を取る → GitHubに上げる」を1周やってみる。

最初の設定（最初の1回だけ）

新しいPCで最初に1回やればいい設定。

# 自分の名前とメールを登録する
# なぜ：コミット(セーブ)に「誰がやったか」の署名として毎回焼き込まれるから
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# 新しいリポジトリの最初のブランチ名を main にする
# なぜ：昔は master が既定だったが、今は GitHub 含め main が標準。合わせておくと後で楽
git config --global init.defaultBranch main

GitHubに安全につなぐ（ghコマンドが一番ラク）

GitHubとの通信は、パスワードではなく「鍵（SSH鍵）」で行うのが今の定石。手でやると鍵の生成〜登録が面倒だけど、GitHub CLI（gh）を使うとコマンドだけで完結する。初心者にはこれが一番おすすめ。

# Mac の場合(Homebrew)。Windowsは winget install GitHub.cli
brew install gh

# GitHubにログイン。対話式で聞かれるので矢印キーで選ぶだけ
# なぜ：push/pullの認証も、SSH鍵の作成〜登録も、これ1つが面倒を見てくれる
gh auth login
#   → GitHub.com を選ぶ
#   → プロトコルは SSH を選ぶ(パスワードより安全)
#   → 「Generate a new SSH key」を選べば鍵作成〜登録まで丸ごとお任せ
#   → ブラウザが開いてワンタイムコードを入れれば完了

# ちゃんとログインできたか確認
gh auth status

鍵を手で作りたい人だけ、ssh-keygen -t ed25519 -C "[email protected]" で作れる（今の推奨方式はed25519。RSAより短くて速く安全）。ただし秘密鍵（.pubが付かない方）はパスワードと同じ。人に見せない・リポジトリに上げない。

基本の流れ：これで1周

ここが本体。「作る → 状態を見る → 載せる → 保存する → 上げる」 を1サイクルやってみる。

# 練習用フォルダを作って入る
mkdir my-first-repo && cd my-first-repo

# このフォルダを git 管理下にする(.git という隠しフォルダができる)
# なぜ：git init しないと git は何も記録できない。ここが履歴管理の開始点
git init

# 適当にファイルを作る(練習)
echo "# My First Repo" > README.md

# 今どういう状態か見る。困ったらまずこれ
# なぜ：どのファイルが「未追跡/変更あり/保存待ち」かを教えてくれる。git の地図
git status

# 保存したいファイルを「保存候補(ステージ)」に載せる
# なぜ：git は変更した全部ではなく「載せたものだけ」を保存する。選べるのが強み
git add README.md
#   全部載せたいなら： git add .   (.gitignore 対象は自動で除外される)

# ステージした内容を1つの履歴(コミット)として確定する
# なぜ：-m はメッセージ。「何をなぜ変えたか」を後の自分が読む。ここが1つのセーブポイント
git commit -m "Add README"

# これまでの履歴(セーブ一覧)を見る
git log --oneline

ここまでは全部ローカル（自分のPCの中）。次でGitHubに上げる。

# GitHub上に空のリポジトリを作って、今のフォルダを紐づけて push まで一気にやる
# なぜ：ブラウザでリポジトリ作成→URLコピー→remote追加…の手順を gh が1発でやる
gh repo create my-first-repo --private --source=. --push
#   --private は非公開。公開にするなら --public

2周目以降（実際の作業はこの繰り返し）

git add .                       # 変更を載せて
git commit -m "Fix login bug"   # 意味の区切りで保存して
git push                        # GitHubに上げる

他人の（or 別PCの自分の）リポジトリを取ってくる

# GitHub上のリポジトリを丸ごとコピーして手元に持ってくる
git clone [email protected]:someone/their-repo.git

# GitHub側の最新の変更を手元に取り込む
# なぜ：他人(や別PCの自分)が push した分を反映しないと、ズレて衝突の元になる
git pull

鉄則：作業を始める前にgit pull。1日の始まりや、共有しているリポジトリでは特に。

ブランチ超入門（軽く）

ブランチ＝履歴の枝分かれ。「本線（main）を壊さずに、別の枝で実験する」ための仕組みだ。レポートに例えると、完成版を触らずにコピーで書き直し、うまくいったら本体に反映するイメージ。失敗しても本線は無傷。

git branch                 # 今あるブランチ一覧(* が今いる場所)
git switch -c feature-login  # 新しいブランチを作って移動
#   (古い教材だと git checkout -b。動作は同じだが、今は switch 推奨)

この枝でadd→commitして、うまくいったら本線に合流（マージ）する。

git switch main            # 本線に戻って
git merge feature-login    # feature-login の成果を main に取り込む

初心者のうちは「1人開発なら main だけでもOK。慣れたら機能ごとにブランチ」で十分だ。

.gitignore（上げたくないものを除外する）

.gitignore＝gitに無視させるファイル一覧。プロジェクトのルートに置くただのテキストファイルで、秘密情報・巨大ファイル・自動生成物をうっかり上げないために使う。一度pushすると履歴に残って消しにくいので、最初に置くのが超重要だ。

# 秘密情報(APIキーやパスワード) — 絶対に上げない
.env
*.key

# 依存ライブラリ(容量が巨大。各自 install で復元できるので不要)
node_modules/
venv/
__pycache__/

# OS/エディタが勝手に作るゴミ
.DS_Store

# ビルド生成物(ソースから作り直せるもの)
dist/
build/
*.log

テンプレは自作しなくていい。GitHubの公式集 github/gitignore に言語別の完成品がある。注意点は、.gitignoreは「これから追跡しないもの」の指定なので、すでにcommitしてしまったファイルは足しても消えない（git rm --cached ファイル名で追跡解除が必要）。だから最初に置く。

GitHub Desktop（GUI）とコマンドの使い分け

結論：初心者はGUIから入ってもいい。むしろおすすめ。

GitHub Desktop を使うと、変更点が色分けで見えて、ボタンでadd/commit/pushができる。「今どのファイルがどう変わったか」を目で確認しながら進められるので、概念の理解が早い。まず「commitとpushって何が違うの？」の感覚をGUIで掴むのが近道だ。

一方コマンド（CLI）は、速い・自動化できる・GUIの無いサーバー上でも使える・エラーの原因が分かりやすい、という強みがあり、実務では結局これが要る。現実的には、最初の1〜2週間はGitHub Desktopで流れを体で覚え、慣れたら同じ操作をコマンドでやってみる。両者は同じgitを裏で叩いているだけなので、いつでも行き来できる。

初心者がやりがちな失敗

やりがちな失敗	なぜマズい	対策
コミットを溜めすぎる	どこで壊れたか特定できない／メッセージが雑になる	機能1つ・バグ1つ直したら1回、と小さく
巨大ファイルを上げる（動画・データ・zip）	リポジトリが重くなり、履歴から消しにくい	`.gitignore`で除外。大容量は別のストレージへ
secret（.env・APIキー）を上げる	公開リポジトリなら数分で悪用される。消しても復元される	最初に`.gitignore`へ。万一上げたらキーを即無効化→再発行
`add`し忘れ	commitしたつもりが空、一部だけ保存される	commit前に必ず`git status`で確認
pullせずに作業開始	他人の変更とぶつかって衝突まみれ	作業前に`git pull`を習慣に
メッセージが`update`や`aaa`	後で履歴を読んでも何をしたか分からない	「何を・なぜ」を短く。例：`Fix null error on login`

まずこれだけ覚えればいい

迷ったらこの8つ＋設定2つ。実務の9割はこれで回る。

git status                 # 今どうなってる?(困ったらまずこれ)
git add .                  # 変更を保存候補に載せる
git commit -m "メッセージ"  # 履歴として保存(セーブ)
git push                   # GitHubに上げる
git pull                   # GitHubの最新を取り込む(作業前に)
git log --oneline          # 履歴を一覧
git switch -c ブランチ名    # 枝を作って移動(実験用)
git clone URL              # 既存リポジトリを手元に取ってくる

覚え方のコアはこれだけ。

statusで見て → addで載せて → commitで保存して → pushで共有。始める前にpull。この5語のループがgitの心臓部。

このコマンドたちを打つ場所（ターミナル）やMacの開発環境そのものの整え方は、こっちにまとめた。