WebサイトやLPを一人で作っているうちは「あ、上書きしちゃった…」「前のファイルどこ？」で済むのですが、2人・3人・外注も混ざる…という段階になると一気にカオスになります。
そこで使われるのがGitによるバージョン管理と、GitHubでのシンプルな開発ルール（GitHub Flow）です。
このページでは、
- Gitを使う前に知っておきたい「CUIの基本」
- Gitでよく出る用語（リポジトリ・コミット・プッシュなど）
- 実際の一連の流れ（ローカル作成 → add → commit → push）
- プルリクエストでレビューを回すやり方
- GitHub Flowでの「最低限これ守っておけばOK」なルール
を、Web制作初心者でもわかるように順番で説明します。
目次
1. Gitの前にちょっとだけCUIに慣れておこう
GitはGUIツール（SourcetreeやGitHub Desktop）でも操作できますが、開発現場ではまだまだコマンドでの操作（CUI）が登場します。
ここだけは避けて通れません。
GUIとCUIの違い
| 項目 | GUI（例：Finder、エクスプローラー） | CUI（例：ターミナル、コマンドプロンプト） |
|---|---|---|
| 操作方法 | マウスでクリック・ドラッグ | キーボードでコマンドを打つ |
| 覚える量 | 少ない・直感的 | 最初はとっつきにくい |
| 開発との相性 | できることに限りがある | サーバー操作・Git操作で強い |
| 代表例 | MacのFinder / Windowsのエクスプローラー | Macの「ターミナル」 / Windowsの「コマンドプロンプト」 |
「黒い画面こわい…」となりがちですが、Gitは“こういう黒い画面で指示を出す”前提で作られているので、最低限だけでも慣れておくと後がラクです。
開き方の例
- Mac：⌘ + Space → 「terminal」入力 → ターミナル起動
- Windows：スタート → 「Windows システムツール」→「コマンドプロンプト」
起動すると最後の行に ~ $ や % が出ているはずです。そこにコマンドを入れます。
よく使う超基本コマンド
| やりたいこと | Mac/Linuxでのコマンド | Windowsでのコマンド |
|---|---|---|
| フォルダを移動する | cd フォルダ名 | cd フォルダ名 |
| 今いる場所の中身を見る | ls | dir |
| デスクトップに移動 | cd ~/Desktop | cd %USERPROFILE%\Desktop |
ここまでできれば、この先のGitコマンドもほぼ同じノリで使えます。
2. Gitってそもそも何をしてくれるの？
一言でいうと「いつ・誰が・どこを変えたかを全部覚えておいてくれる仕組み」です。
Web制作でよくある、
- 画像だけ差し替えるはずがCSSも書き換えてた
- Aさんが昨日直したところをBさんが今日のアップで消しちゃった
- 古い版に戻したいけど、どれが最新かわからない
を防ぐためのものです。
さらにGitは分散型なので、みんながそれぞれ自分のPCに“完全な履歴入りのコピー”を持てます。
つまり、ネットが切れても作業できるし、あとで中央（GitHub）に送ることもできます。
3. Gitでよく出る用語を先にざっと押さえる
このあたりは“単語の意味がわかるだけ”でも一気に読みやすくなるので、表で確認してください。
| 用語 | ざっくりの意味 | どんなときに使う？ |
|---|---|---|
| リポジトリ（repository） | 変更履歴つきでファイルをしまっておく場所 | プロジェクトの“箱”だと思えばOK |
| ローカルリポジトリ | 自分のPCの中にあるリポジトリ | 手元で直すとき |
| リモートリポジトリ | GitHubなどネット上にあるリポジトリ | チームと共有するとき |
| コミット（commit） | その時点の変更を「ここまでやった」と記録する | 作業の区切りごとに実行 |
| プッシュ（push） | ローカルの変更をリモートに送る | チームに成果を共有したいとき |
| プル（pull） | リモートの最新をローカルに取り込む | 他の人が先に進めていたら先にpull |
| クローン（clone） | リモートをまるごと手元にコピーする | プロジェクトに初参加するとき |
| ブランチ（branch） | 履歴を分岐させる仕組み | 新機能・修正を安全にやるとき |
| マージ（merge） | 分岐した履歴を元に戻す | 作業が終わったらmain/masterに戻す |
ここまでで「なんかよく聞くやつ」がだいたい見えてきたと思います。
4. ファイルがGitで管理されるまでの3つの場所を理解する
Gitには実は「いきなり保存」ではなく、段階的に保存する仕組みがあります。
- ワークツリー（作業ツリー）：いま実際に編集しているところ
- インデックス（ステージ）：今回のコミットに入れるものを一時的に置く場所
- ローカルリポジトリ：正式に履歴として残る場所
作業ディレクトリ →（git add）→ ステージングエリア →（git commit）→ ローカルリポジトリ
この「addしてからcommit」があるから、「この画像はまだコミットしたくない」「このCSSだけ先にチームへ出したい」ができるわけです。
5. 実際の基本フローをやってみる
ここでは「portfolio_site」というフォルダをGitで管理する流れでいきます。
① Gitの初期化
cd ~/Desktop
mkdir portfolio_site
cd portfolio_site
git init
これでこのフォルダがGitの管理下になります。
.git という隠しフォルダができていればOK。
② ファイルを作る
touch index.html
touch style.css
※Windowsなら
type nul > index.html
type nul > style.css
index.html にはとりあえずこんな感じで入れておきます。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>My Portfolio</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<h1>デザイナー・コーダー向けポートフォリオ</h1>
</body>
</html>
style.css はこんな感じでOKです。
h1 {
background: #ffe8b5;
padding: 16px;
}
③ 変更をステージに載せる（git add）
git add index.html
git add style.css
# 一気にやるなら
# git add .
④ 状態を確認する（git status）
git status
ここで緑色なら「コミット対象になりますよ」という意味、赤色なら「まだaddされてないです」という意味です。
⑤ コミットする（git commit）
git commit -m "ポートフォリオの初期ファイルを追加"
コミットメッセージは「自分以外が見ても意味がわかる」ように書きましょう。
後でプルリクにするときも読みやすくなります。
6. GitHubに上げてチームと共有する（remote設定 → push）
リモートに上げるには、先にGitHub側で空のリポジトリを作っておき、URLを控えておきます。
git remote add origin https://github.com/yourname/portfolio_site.git
git branch -M main # mainにしておくと今風
git push -u origin main
最初だけGitHubのユーザー名・アクセストークンを聞かれます。
ここまでできると「自分のPC → GitHub」のラインがつながったことになります。
7. プルリクエストでレビューしてもらう流れ
チーム開発では「いきなりmainにpush」は基本NGにします。
なぜなら本番に近いブランチを汚したくないからです。
そこでブランチを切って → そこで作業して → GitHubでプルリクを出すという流れにします。
ブランチを作って移動
git checkout -b feature/header
これで「ヘッダーを作るための作業専用ライン」ができました。
作業 → add → commit → push
# ファイルを編集したあと
git add .
git commit -m "ヘッダーにナビゲーションを追加"
git push origin feature/header
GitHubでPRを作る
GitHubに行くと「Compare & pull request」が出ているので押す →
- どのブランチにマージしたいか（mainかdevelopか）
- どんな変更か
- 誰に見てほしいか
を書いて「Create pull request」を押せばOKです。
これで「レビューしてからmainに入れる」という安全運転になります。
8. GitHub Flowを知っておくと“最低限の型”が身につく
GitHub Flowは、もっともシンプルなブランチ運用です。
複雑なreleaseブランチやhotfixブランチを使わないので、Web制作チームや小規模プロジェクトと相性がいいです。
GitHub Flowで守ること
- main（またはmaster）はいつでも公開できる状態にしておく
- 作業は必ず新しいブランチを切ってやる（
feature/〇〇など） - こまめにGitHubへpushして状況を共有する
- マージ前に必ずプルリクエストを作る
- レビューでOKが出たらmainにマージ
- マージできたらすぐにデプロイして現場に反映
- 使い終わったブランチは削除しておく（あとで復元も可能）
流れを表で見ると…
| 手順 | やること | コマンド例 |
|---|---|---|
| 1 | mainから作業ブランチを作る | git checkout -b feature/footer |
| 2 | コーディングする | — |
| 3 | add & commit | git add . / git commit -m "フッター追加" |
| 4 | リモートにpush | git push origin feature/footer |
| 5 | GitHubでPRを作る | 画面から操作 |
| 6 | レビュー後にmainへマージ | 画面から操作 |
| 7 | ブランチを削除 | git branch -D feature/footer |
この型ができていると、誰がどの作業をしているかが一発で見えるので、後から入った人もキャッチアップしやすくなります。
まとめ｜チーム開発でGitが重要になる理由
最後に、この章の学習目的にあった「なぜバージョン管理が必要なのか」をまとめておきます。
- 更新履歴を残せる：誰が・いつ・どのファイルを変更したか追跡できる
- 変更を巻き戻せる：誤って上書きした場合でも以前の状態に戻せる
- 同時作業ができる：ブランチを分ければ、デザイナーとコーダーが同時に別機能を作っても衝突しにくい
- レビュー文化を作れる：プルリクエストでコードを見合うことで品質が安定する
- リモートワークと相性がいい：GitHubを中心にすれば、場所がバラバラでもプロジェクトを回せる
