Githubが使えるようになりたい。
具体的にGitthubでは何を期待しているのか?
自分の書いたソースコードを管理したい。 1日に何個もソースコードを書くとそれの管理のためにwordpressに使うのは、 はっきり言って不便だ。
それよりも一旦作ったものを時間別で管理をして修正したちときにするという状態にしたい。 また、それをアップデートしたいときにできるようにしたい。
また、そこから派生したコードブランチができた場合も正しく管理をしたい。
OK、結論から
あなたがGitHubに期待すべきこと=時系列での変更履歴・安全な“やり直し”・派生(ブランチ)管理・配布(公開)。WordPressでやるのは不向き。GitHubに一本化しよう。
GitHub Desktopのインストール方法
https://docs.github.com/ja/desktop/installing-and-authenticating-to-github-desktop/installing-github-desktop
まず決めること(設計)
- 運用形態:1リポジトリに小さな作品をどんどん入れる“モノレポ”
例:wp-toys/2025/08/11/jumping-ball/index.html - 命名規則:
YYYY/MM/DD/slug+index.html(WP埋め込み前提の単一ファイル) - コミット規約:
feat: ... / fix: ... / refactor: ...(Conventional CommitsでOK) - タグ(時刻付き):
2025.08.11-0905-jumping-ball(いつ・何を出したか一発でわかる) - ブランチ運用:
main(完成物)/feature/*(派生や実験)/fix/*(修正)
最短の初期セットアップ(1回だけ)
# 1) ローカルで設定
git config --global user.name "あなたの名前"
git config --global user.email "あなたのメール"
# 2) 新規フォルダ作成
mkdir wp-toys && cd wp-toys
echo "# wp-toys" > README.md
printf ".DS_Store\nnode_modules/\n" > .gitignore
# 3) 初回作業ディレクトリ
mkdir -p 2025/08/11/jumping-ball
$EDITOR 2025/08/11/jumping-ball/index.html # ←あなたのコード貼り付け
git init
git add .
git commit -m "feat: add jumping-ball MVP"
# 4) GitHubで空リポ(例: attrip/wp-toys)を作成後、紐づけてプッシュ
git branch -M main
git remote add origin git@github.com:attrip/wp-toys.git # or https://... でも可
git push -u origin main
# 5) タグ(時間刻み)
git tag 2025.08.11-0948-jumping-ball
git push origin --tags
日々の運用(あなたの“書き散らし”に最適化)
新作を追加
mkdir -p 2025/08/11/maze-cat
$EDITOR 2025/08/11/maze-cat/index.html
git add .
git commit -m "feat(maze-cat): first playable MVP"
git push
git tag 2025.08.11-1020-maze-cat && git push origin --tags
既存作を“ちょい直し”
git switch -c fix/jumping-ball-speed # 直すときは枝を切る
$EDITOR 2025/08/11/jumping-ball/index.html
git add .
git commit -m "fix(jumping-ball): adjust speed and collision"
git push -u origin fix/jumping-ball-speed
# GitHub上でPR→レビュー(自分でOK)→mainにマージ→タグ
git switch main
git pull
git tag 2025.08.11-1103-jumping-ball && git push origin --tags
“派生版”を作る(ブランチで分ける→別フォルダに落とすも可)
git switch -c feature/jumping-ball-hard-mode
# 実験的変更を加える
git add .
git commit -m "feat(jumping-ball): hard mode prototype"
git push -u origin feature/jumping-ball-hard-mode
# 良ければ main へマージ、別ラインで残したいならフォルダを複製して共存させる
フォルダ構成の例(見てわかる・触ってすぐ動く)
wp-toys/
README.md
.gitignore
2025/
08/
11/
jumping-ball/
index.html
maze-cat/
index.html
“公開”までやりたいなら(任意)
- GitHub PagesをONにして、
/docsにビルドやコピーファイルを置けばURLで試遊可能。
面倒なら最初は未導入でOK。慣れたらActionsでmainマージ時に/docsへ自動コピー。
破壊的な事故から守る最低限のルール
mainへ直コミット禁止(PR経由)。- 小さく頻繁にコミット(1機能/1修正 = 1コミット)。
- タグは必ず打つ(過去の“その時点”へ即復元できる)。
GitHub Desktop派(CLIが面倒なら)
- アプリで「Clone/Create→Commit→Publish Branch→Create Pull Request」のボタンを押すだけ。
- 視覚的に差分が見える。最初はこれで十分。
ここまでやれば、時間別の管理・修正の追跡・アップデート・派生ブランチ、全部クリア。
まずはリポを1本つくって、今日のコードを2本入れて、2回コミット→1回タグ。そこから回そう。
いや、必ずしもターミナルじゃなくてもOKです。
GitHubは3つの操作スタイルがあります。
1. ターミナル(コマンドライン)
- 最も自由度が高く、公式ドキュメントもこれ前提。
- 他人のコードを扱うときや、自動化したいときに強い。
git init / git add / git commit / git pushなどのコマンドで操作。- プログラマっぽくガシガシやりたいならこれ一択。
2. GitHub Desktop(GUIアプリ)
- マウスだけで「追加 → コミット → プッシュ → ブランチ作成」ができる。
- ファイル変更の差分が視覚的に見える。
- インストールしてGitHubアカウントにログイン → 新規リポジトリ作成か既存をクローン → ファイルを放り込むだけ。
- ブランチやタグもメニューから選択可能。
3. GitHub Webエディタ(ブラウザ)
- リポジトリページで「Add file → Upload files」で直接アップロードできる。
- 簡単だけど履歴の粒度管理やブランチ運用はやりづらい。
- 修正もブラウザのペンアイコンから直接編集可能(ただし小規模向け)。
💡 あなたの用途(1日に複数コード、時間別管理、派生管理)だと
最初はGitHub Desktopが一番ラク → 慣れたらターミナルへ移行がベスト。
もし希望があれば、
「GitHub Desktopだけで今日から管理開始するための手順」
をあなた用に作ります。
やりますか?
もちろんやるよ。
よし、GitHub Desktopだけで今日から回す手順を一気に出す。ターミナル不要。
ゴール
- 1日の複数コードを時系列で管理
- 修正は履歴で可視化
- 派生はブランチで分岐
- 仕上がりはタグで保存(いつでもその時点へ戻せる)
0. 事前準備(5分)
- GitHub Desktop をインストール → サインイン
- GitHub(ブラウザ)で公開リポを1本作る:例
attrip/wp-toys(PrivateでもOK) - Finder/エクスプローラで作業フォルダを用意(例:
~/Projects/wp-toys)
1. リポを作って同期
- GitHub Desktop → File > New repository…
- Name:
wp-toys - Local path:
~/Projects/wp-toys - Initialize with README にチェック
- Create Repository → Publish repository で GitHub に公開
- Name:
2. フォルダ設計(時系列×作品単位)
Finderで下記を作る(後でテンプレにする)
wp-toys/
README.md
.gitignore
2025/
08/
11/
jumping-ball/
index.html
maze-cat/
index.html
- 命名:
YYYY/MM/DD/slug/index.html .gitignoreには最低限:.DS_Store node_modules/
3. 「追加→コミット→プッシュ」(Desktopの基本動線)
- GitHub Desktop 左側の変更一覧に新規/更新ファイルが出る
- 下部の Summary に、Conventional Commitsで短文
- 新規:
feat(jumping-ball): first playable MVP - 修正:
fix(jumping-ball): adjust speed
- 新規:
- Commit to main → 右上の Push origin
4. ブランチ運用(派生や実験)
- 右上 Current branch > New branch
feature/jumping-ball-hard-modeなど
- 変更 → コミット → Publish branch
- 良ければ Create Pull Request(Desktopからボタン1発)
- ブラウザで自分レビュー→Merge
- Desktop側で Fetch origin → Delete branch(ローカル/リモート両方消してスッキリ)
5. タグ付け(“この時点”を固定)
方法A:Desktop
- メニュー Repository > Create Tag…
- Tag name 例:
2025.08.11-1103-jumping-ball - Push origin(タグも一緒に上がる)
- Tag name 例:
方法B:GitHub(Web)のReleases
- Releases > Draft a new release → Tag を新規作成 → Publish
6. 今日やる最短タスク(20分で回す)
2025/08/11/jumping-ball/index.htmlを入れて featコミット→Push- タグ:
2025.08.11-1st-jumping-ballを作成→Push - バランス調整して fixコミット→PR→Merge(自分でOK出し)
- 2本目
maze-catを追加して featコミット→Push - タグ:
2025.08.11-1st-maze-cat
7. GitHub Pages(任意:URLで試遊したいとき)
- リポの Settings > Pages
- Source:
GitHub Actionsかmain / /docs
- Source:
- まずは簡単に
/docsを作ってコピー運用:docs/2025/08/11/jumping-ball/index.htmlを置く- Push → 数分で公開URLが出る
- 慣れたら PR マージ時に
docs/へ自動コピーするActionsを足す(後で一緒にやればOK)
8. 運用ルール(事故防止の最低限)
- main直コミット禁止(必ずブランチ→PR→Merge)
- 小さく頻繁にコミット(1機能=1コミット)
- 必ずタグ(公開/配布/節目はタグ打ち)
9. つまずきポイントと回避
- 「ファイルが反映されない」→ Desktop右上Pushを忘れてる
- 「PRボタンが出ない」→ ブランチをPublishしてない
- 「衝突(Conflict)が怖い」→ 1日1作品あたり短サイクルでMergeして溜めない
- 「履歴が汚れる」→ Summaryは短く、Bodyに詳細を書く
10. 明日からの定着リズム
- 朝:新作用
feature/slugを切る - 昼:MVP→PR→Merge→タグ
- 夜:改善点を Issue に箇条書き、明日へ繰越
まずここまでやってみる。