GitHub初心者のためのビジュアルガイド

ゼロから始めるバージョン管理と共同開発の世界へようこそ

Step 1: 基本のキ - 道具と場所を理解する

Git vs. GitHub: 役割の違い

初心者が最初につまずきやすいのが「Git」と「GitHub」の違いです。簡単に言うと、GitはあなたのPCで動く「バージョン管理の道具」、GitHubはその道具で作ったものを保管・共有する「インターネット上の場所」です。

特徴	💻 Git (道具)	☁️ GitHub (場所)
役割	ファイルの変更履歴をPC上で記録・管理するソフトウェア。	Gitの履歴をネット上で保管し、チームで共有するためのウェブサービス。
作業場所	ローカルPC (オフラインでもOK)	クラウド (インターネット接続が必要)
例えるなら	文章を書くための「Word」ソフト	Wordファイルを共有・共同編集する「Google Docs」

Step 2: 一人で使ってみる - 基本的なサイクル

個人のプロジェクト管理フロー

まず、一人でプロジェクトを進める際の基本的な流れを覚えましょう。GitHub上のプロジェクトを手元にコピーし、変更を加えて、またGitHubに戻す。このサイクルがすべての基本です。

①

Clone (複製)

GitHubからPCへ

②

Edit & Add & Commit (編集と記録)

PC上で作業

③

Push (送信)

PCからGitHubへ

Step 3: チーム開発の核心 - ブランチを使いこなす

安全に作業するための「ブランチ」

チーム開発では、元のコード（mainブランチ）を直接編集しません。代わりに、自分の作業用の「コピー（ブランチ）」を作成し、そこで作業します。これにより、他の人の作業に影響を与えることなく、安全に新機能の追加やバグ修正ができます。

🌿 mainブランチ (本番用の安定したコード)

👤 Aさんの作業

🌿 login-featureブランチ

👤 Bさんの作業

🌿 bug-fixブランチ

作業が終わったら、自分のブランチをmainブランチに「マージ（統合）」します。

Step 4: 共同作業の作法 - プルリクエスト

変更を提案し、レビューを受ける

自分のブランチでの作業が完了したら、「この変更を取り込んでください」とチームに依頼します。この依頼が「プルリクエスト」です。プルリクエストを通じて、チームメンバーは変更内容を確認（コードレビュー）し、問題がなければ承認します。

①

プルリクエスト作成

「この変更どうでしょう？」

②

コードレビュー

「ここ、もっと良くできるかも！」

③

マージ (統合)

「OK！取り込みます」

Step 5: プロジェクトを魅力的に見せる

README.md：プロジェクトの顔

`README.md`は、プロジェクトのトップページに表示される説明書です。訪問者が最初に目にするこのファイルで、プロジェクトの目的や使い方を分かりやすく伝えましょう。

✓ 概要: このプロジェクトが何をするものか
✓ インストール方法: どうやって使い始めるか
✓ 使い方: 具体的な使用例

.gitignore：不要なファイルを無視

パスワードなどの機密情報や、OSが自動生成するファイルは、リポジトリに含めるべきではありません。`.gitignore`ファイルにファイル名を書いておくことで、Gitがそれらを無視するようになります。

# OSファイル

.DS_Store

# 機密情報

.env

# 依存パッケージ

/node_modules

Step 6: 次のステップへ - 良いコミットメッセージ

コミットの種類を意識する (Conventional Commits)

コミットメッセージは「何を変更したか」を明確に伝えるための重要な記録です。「Conventional Commits」という規約に従うと、履歴が分かりやすくなります。例えば、コミットの種類を`feat`（新機能）、`fix`（バグ修正）のように接頭辞で示します。

このグラフは、典型的なプロジェクトにおけるコミットの種類のおおよその割合を示しています。バグ修正（fix）や新機能追加（feat）が多いことがわかります。