GitHub入門ガイド：リポジトリ、Commit、Forkから「1日1コミット」まで

多くの人が初めてGitHubを開くと、Repository、Commit、Branch、Pull Request、Fork、Star、Watch、Issue、Actions といった英語のボタンに圧倒されてしまい、プログラマー向けの専用ツールだと感じてしまいます。

しかしGitHubは、まず次の一文でシンプルに理解できます。

GitHub = コードを保管し、変更を記録し、協調開発を行い、プロジェクトを公開・展示するためのサイト。

AIツール、Claude Code、Codex、Cursor、Vercel、Next.js、Pythonプロジェクトを学習している場合、GitHubはほぼ避けて通れません。多くのオープンソースプロジェクトがGitHub上でホスティングされ、また多くのWebサイトのデプロイもGitHubリポジトリに接続されています。

この記事ではすべてのGitコマンドを一度に網羅することを目指しません。まずはGitHub画面で最もよく見かける概念とボタンを理解することから始めます。画面を理解してからコマンドを順に学ぶ方が、ずっと楽に進められます。

一、GitとGitHubは同じもの？

違います。

簡単に言えば：

Gitはツール、GitHubはプラットフォームです。

自分のPCでGitを使ってコードを管理でき、コードをGitHubにプッシュして保存・公開することもできます。Gitは基盤的なツール、GitHubはGitを中心に構築されたWebサイト兼協業プラットフォームです。

二、Repository：リポジトリとは？

Repository は通常 repo と省略され、英語のままでも使われます。日本語では「リポジトリ」と呼びます。

リポジトリとは、あるプロジェクトのフォルダーです。例えば：

my-website/
├── README.md
├── package.json
├── src/
└── public/

GitHub上では、1つのリポジトリに通常以下が含まれます。

• プロジェクトのコード
• プロジェクト説明書
• 変更履歴
• Issueの議論
• Pull Requestの協業記録
• Actionsの自動化フロー

自分のサイト、Pythonツール、AI Agentプロジェクトを公開したいなら、GitHubリポジトリを作成できます。個人学習者にとって、リポジトリはコードのバックアップ先であるだけでなく、長期的な作品集としても機能します。

三、README：プロジェクトの説明書

README.md はGitHubプロジェクトで最も重要な説明ファイルの1つです。

他の人があなたのリポジトリを開くと、GitHubは通常READMEの内容を自動表示します。READMEは、できるだけ明確に以下を説明するのが理想です。

1. このプロジェクトが何をするものか。 2. どのようにインストールし、実行するか。 3. 主要機能は何か。 4. どの技術を使っているか。 5. スクリーンショットやデモリンクがあるか。 6. 作成者、ライセンス、その他の注意事項。

個人プロジェクトでは、READMEが読みやすいほど、単にコードだけを積み上げるより、他人があなたの能力を素早く理解しやすくなります。特に履歴書向けプロジェクト、ポートフォリオ、オープンソース学習プロジェクトでは、READMEがプロジェクトの「表の顔」に相当します。

四、Commit：コミットとは？

Commit は「1回分の保存版を作ること」と理解できます。

変更を小さく進めるごとに1回コミットを作成し、その時点の状態を記録します。例えば：

1回目のコミット：プロジェクト初期化
2回目のコミット：ホームページのレイアウトを追加
3回目のコミット：検索機能の不具合を修正
4回目のコミット：READMEを更新

Commitの意味は「適当に保存を押す」ことではなく、プロジェクトの変更履歴を明確に残すことです。後から「この機能はいつ追加されたか」「このバグがいつ発生したか」を見返せるようになります。

良いコミットメッセージは、何をしたかを簡潔に書くべきです。例えば：

Add homepage layout
Fix broken search filter
Update README installation guide
Refactor API request logic

中国語のプロジェクトでも中国語で書いて問題ありません。

ホームページのレイアウトを追加
検索フィルターの不具合を修正
READMEのインストール手順を更新
APIリクエストロジックをリファクタリング

初心者が最初から高度なコミット規約を厳密に守る必要はありませんが、少なくとも aaa、test、随便改改 のように意味がほとんど伝わらない内容は避けるべきです。

五、Git commit の身元は何で決まる？

初心者がよく誤解するのは次です。

VS CodeでGitHubにログインしているから、commitの作者はそのGitHubアカウントになる。

これは完全には正しくありません。

Git commit の作者情報は主にローカルGitの設定で決まります。つまり：

git config user.name
git config user.email

現在のプロジェクトで使われているGitの身元を確認するには、ターミナルで次を入力します。

git config user.name
git config user.email

グローバル設定を変更したい場合は、次を入力します。

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

次の点に注意してください。

VS Code / GitHubログイン：主にpush、pull、リモートリポジトリへのアクセスに使用。
Git commit の作者情報：主にgit configのuser.nameとuser.emailで決まる。

そのためGitHubアカウントを切り替えた後は、ローカルGit設定を確認して、コミットが古いメールアドレスや古い名前で表示されないようにするのが安全です。

六、MainとBranch：メインラインとブランチとは何か？

ここはGitHub初心者がつまずきやすい箇所です。

多くの人は main、branch、merge、pull request を見て、これらが別々のフォルダーだと思ったり、branchはプロジェクトを丸ごとコピーするものだと誤解したりします。

より正確には次のとおりです。

main = プロジェクトのメインラインで、通常は最も安定し正式なコードを表す。
branch = ある時点から分岐した変更の流れ。実験や新機能開発を安全に行うために使う。

GitHub公式ドキュメントでは、新規リポジトリにはデフォルトブランチが含まれると説明されています。人がリポジトリを開いてコードを見たりクローンしたりするとき、通常はこのデフォルトブランチが表示されます。最近の新規プロジェクトでは main がデフォルト名ですが、古いプロジェクトでは master の場合もあります。

1. まずは日常的なたとえで理解する

1つのプロジェクトを、現在書いている記事だと思ってください。

main は公開用の完成稿のようなものです：

正式な記事.docx

今、ある章を大きく書き換えたいけれど、元文書を壊したくないため、直接公開稿を編集しません。代わりに下書きを作ります：

正式な記事.docx
第2章の修正版.docx

下書きの中で自由に修正していきます。良ければ正式稿に反映し、だめなら下書きを捨てればよく、正式稿は影響を受けません。

Gitではこの「下書きルート」のことを branch と呼びます。

ただし、Gitのbranchはプロジェクト全体を重くコピーするものではないことに注意してください。Git公式ドキュメントの git branch 説明では、ブランチは現在のHEADまたは指定した起点を指す新しいbranch headを作成するとされています。初心者向けには、次のように理解すると良いでしょう。

branchはプロジェクトを丸ごと複製するのではなく、特定のコミットから新しい変更ルートを記録する。

2. なぜbranchが必要？

実際のプロジェクトでは、同時にいくつもの作業が発生しやすいからです。

本線コードの安定維持;
新機能を開発したい;
誰かがbug修正を担当;
別の人がREADMEを書き直している;
本番環境で急な障害が発生し、緊急対応が必要

全員が main を直接編集すると、プロジェクトはすぐ混乱します。1人のミスが全員に影響します。

そのため、より安全なやり方は次です。

mainは安定状態を保つ
新機能はfeatureブランチで開発
バグ修正はfixブランチで対応
ドキュメント変更はdocsブランチで編集
問題なければmainへマージ

例えば：

main
├── feature/search-page
├── fix/mobile-layout
└── docs/update-readme

これはメイン道路から複数の作業レーンが分岐するイメージです。作業レーンでは改造・試行錯誤・やり直しができます。修正できたらメインに戻します。

3. mainとは何か？

main は通常、リポジトリのデフォルトブランチであり、プロジェクトのメインブランチです。

main は次のように考えると分かりやすいです。

このプロジェクトで現在外部に提示している主要バージョン。

よくある状況:

• 他の人があなたのGitHubリポジトリを開くと、通常 main が初期表示になる
• 他の人がリポジトリをクローンすると、通常ローカルにまず main が取得される
• Vercelのようなサイトデプロイ基盤は、よく main ブランチの更新を監視する
• チーム開発では main は常に実行可能・デプロイ可能・比較的安定であることが求められる

なので初心者は次の習慣を持つと良いです。

main上で大規模変更は軽々としない。

小規模な個人学習プロジェクトなら直接 main を編集しても問題ありませんが、正式なプロジェクトでは新しいブランチを作ってから変更するのが安全です。

4. branchとは？

branch は「分岐」です。

次のように理解します。

mainのあるバージョンから分岐し、独立して一連の変更を行う。

たとえばあなたのサイトが現在 main 上で安定しているとします。

main: トップページ正常、記事ページ正常、検索正常

コメント機能を追加したいけれど、壊してしまうか不安なので新しいブランチを作ります。

feature/comment-system

このブランチでコメント機能を開発し、次の状態になります。

mainはそのまま維持される
feature/comment-systemでは自由に変更できる

テストして問題がないことを確認したら、このブランチを main にマージします。

5. branchとforkは違う

branch と fork を混同しやすいです。

例えば：

自分のリポジトリで feature/search-page を作る → branch
他人のプロジェクトを自分のアカウントにコピーする → fork

つまり：

branchは同一リポジトリ内の分岐
forkはリポジトリ間のコピー

6. 最もシンプルなブランチワークフロー

初心者はこの流れを覚えておけば十分です。

1. mainが安定バージョン
2. mainから新しいbranchを作成
3. branchでファイルを変更
4. commitで変更を保存
5. GitHubへpush
6. Pull Requestを作成
7. 問題なければmainにmerge
8. 完了したbranchを削除

実際の作業に対応させると：

main
→ feature/update-homepage を新規作成
→ トップページを修正
→ commit: Update homepage layout
→ push
→ Pull Request
→ merge into main

マージ後、main に新機能が反映されます。

7. よく使うブランチ命名

ブランチ名は、何をしているかがわかるものがよいです。

よくある書き方：

feature/login-page
feature/search-function
fix/mobile-navbar
docs/update-readme
refactor/api-client

おおまかな規則は次の通りです。

初心者は命名規約を厳密に気にしすぎる必要はありませんが、test1、newnew、final-version のように意味不明な名前は避けましょう。

8. mainとbranchを1行でまとめる

こう覚えるとわかりやすいです。

mainは本線、branchは支線。
mainは安定した公開用、branchは安全な変更用。
branchでうまく整えたら、Pull Requestでmainへマージする。

個人プロジェクトなら、最初は main へ直接コミットしても構いません。しかしプロジェクトが複雑になったり、サイトを壊すリスクが不安になったら、branchを使い始めるべきです。

七、Pull Request：PRとは？

Pull Request は略して PR。次のように理解できます。

一部を変更したので確認をお願いします。問題がなければ本体プロジェクトに取り込んでください。

PRはチーム開発やオープンソースで一般的です。

たとえば他人のプロジェクトをforkしてバグを修正し、PRを作者に送るケースがあります。作者は変更内容を確認し、議論し、修正要請をして、最終的に取り込み可否を決定します。

PRは単なる「コードのアップロード」ではなく、レビュー・議論・マージを行う協業ワークフローです。GitHub公式ドキュメントでも、Pull Requestは変更提案、フィードバック受け、コンフリクト解決、そしてマージ推進の仕組みと説明されています。

八、Fork：フォーク/派生とは？

Fork は次のように理解します。

他人のGitHubリポジトリを自分のアカウントにコピーする。

Forkすると、自分のコピー内で自由に変更でき、元プロジェクトには影響を与えません。

典型的な流れは：

オープンソースプロジェクトを見つける
→ Forkをクリック
→ 自分のforkリポジトリで修正
→ commitを作成
→ Pull Requestを作成
→ 元プロジェクトにマージを依頼

初心者にとってforkの代表的な用途は2つです。

1. 他人のプロジェクト構成を学ぶ 2. 他人のオープンソースを基に二次開発する

ただし、forkは著作権を所有することを意味しません。第三者のプロジェクトを利用する前にライセンスを確認し、コピー・改変・商用利用・再配布が許可されているかを確認してください。

九、Star：スター（お気に入り）とは？

Star はGitHub上の「お気に入り」または「いいね」に相当します。

価値のあるプロジェクトを見つけたらStarを付けて、あとで見返しやすくできます。

スター数はそのプロジェクトの人気をざっくり測る目安になることがありますが、唯一の基準ではありません。スターが多いからといって必ずしもあなたに合うわけでもなく、スターが少ないから価値が低いわけでもありません。

AI、Agent、フロントエンド、Pythonを学ぶ場合、Starは「自分だけのオープンソースブックマーク」として使えます。

十、Watch：更新をフォローする

Watch は、リポジトリの通知をフォローすることです。

あるプロジェクトをWatchすると、GitHubはIssue、PR、Releaseなどの更新をあなたに通知する可能性があります。

初心者はあまり多くのプロジェクトをWatchしすぎない方が良いです。通知が膨大になりやすいです。

このように理解できます。

十一、Issue：問題、提案、議論

Issue はプロジェクト内の「課題票」または「ディスカッション投稿」です。

よくある用途は次の通りです。

• バグ報告
• 新機能提案
• TODO管理
• プロジェクト内の議論
• 使い方の質問

例えば：

Bug: Search does not work on mobile
Feature request: Add dark mode
Question: How to configure API key?

自分のプロジェクトでもIssueで作業項目を管理できます。たとえば自分のサイト用に次のようなIssueを作っておくとよいです。モバイル表示の修正、SEO説明の追補、記事検索の追加、README整理など。そうすることで、プロジェクトが「散在するファイルの寄せ集め」ではなく、実際の工程を持つ作品になります。

十二、Actions：自動化フロー

GitHub Actions はGitHubに組み込まれた自動化ツールです。

push後に自動で実行できるものの例：

• 自動テスト
• 自動ビルド
• 自動デプロイ
• コードフォーマットのチェック
• リリースの作成

たとえば多くのVercel、Next.js、Pythonプロジェクトは、GitHub Actionsや他のデプロイ基盤と組み合わせて自動化を実現しています。

初心者は最初からActionsを深く学ぶ必要はありません。commit、push、branch、PR を身につけた段階で学ぶと、自然に理解できます。

十三、Codeボタン：リポジトリをダウンロードし、URLをコピーする

GitHubのリポジトリページで、緑色の Code ボタンは重要です。

これをクリックすると通常次が表示されます。

• HTTPSアドレス
• SSHアドレス
• GitHub CLIアドレス
• Download ZIP

よく使うコマンド：

git clone https://github.com/username/project-name.git

これは、リモートのGitHubリポジトリをローカルPCにダウンロードする意味です。

Gitを使わずに単にコードを見たいときは、次を使えます。

Download ZIP

プロジェクト全体をzip圧縮して取得します。

十四、Push、Pull、Cloneはそれぞれ何か？

これらの語は非常によく出てきます。

シンプルな流れは次のとおりです。

リポジトリをcloneしてローカルへ
→ ファイルを修正
→ commitで変更を記録
→ pushでGitHubへアップロード

他の人もリモートを変更していた場合は次です。

pullで最新内容を取得
→ 続けて変更
→ commit
→ push

十五、1日1コミットとは何か？

「1日1コミット」は一般に、毎日GitHub上で1回有効な貢献を行い、貢献グラフを連続させることを指します。

GitHubのプロフィールには緑色の貢献グラフがあり、日ごとの貢献状況を表示します。貢献にはcommit、pull request、issue、discussionなどが含まれることがありますが、どの活動が表示対象かにはルールがあり、すべてがカウントされるわけではありません。

初心者は次を意識してください。

1日1コミットは、緑のマスを埋めるためではなく、継続的にプロジェクトを改善する習慣をつけるためにある。

健康的なやり方としては、毎日小さな実質的な変更を行うことです。たとえば：

• READMEの一部説明を修正する
• 小さなバグを1つ修正する
• 小規模な機能を追加する
• プロジェクト構成を整理する
• 学習ノートを1件追加する
• ページのスタイルを一箇所最適化する
• テストケースを1つ追加する

意味のない空コミットを増やすためだけの提出は推奨しません。たとえば空白1つ直すだけで日次を埋めるような行為は、成長や作品性の向上にほとんど役立ちません。

十六、初心者向け1日1コミット練習法

毎日のコミット内容が分からない場合は、以下のペースで進めると良いです。

1. 1日目：リポジトリを作成

新規リポジトリを作成します。例えば：

github-learning-notes

READMEを追加し、このリポジトリがGitHub学習ノートを記録するためのものだと明記します。

2. 2日目：GitHubの基本語彙を追加

READMEに以下を追記します。

Repository = リポジトリ
Commit = コミット
Branch = ブランチ
Pull Request = プルリクエスト
Fork = フォーク / 派生

3. 3日目：コマンドラインのノートを追加

新しいファイルを追加します。

command-line-basics.md

ls、cd、mkdir、pwdなどのコマンドを記録します。

4. 4日目：Gitコマンドノートを追加

新規追加：

git-basics.md

以下を記録します。

git status
git add .
git commit -m "Update notes"
git push

5. 5日目：ディレクトリ構成を整理

ノートを次のように整理します。

github-learning-notes/
├── README.md
├── notes/
│   ├── command-line-basics.md
│   └── git-basics.md
└── resources.md

6. 6日目：参考資料を追加

resources.md を追加し、GitHub Docs、Git公式ドキュメント、優れたオープンソースプロジェクトのリンクを記録します。

7. 7日目：1週間の振り返りを書く

READMEに以下を追記します。

今週私は何を学んだか？
何がまだ理解できていないか？
次にやりたいことは何か？

これは機械的なコミットより価値があります。最後には、学習プロセス自体を示す実体のあるプロジェクトが残るからです。

十七、初心者がよく使うGitコマンド

VS Codeを使っている場合、グラフィカル操作で多くの作業を行えますが、次のコマンドは理解しておくと助けになります。

現在の状態を確認：

git status

変更をステージングエリアへ追加：

git add .

変更をコミット：

git commit -m "Update README"

GitHubへプッシュ：

git push

GitHubから最新内容をプル：

git pull

コミット履歴を確認：

git log --oneline

初心者はまずこの数個のコマンドを慣れるのがよいです。最初から難しいコマンドを覚える必要はありません。実際にプロジェクトを書いているうちに、ブランチ切替、コンフリクト解消、バージョン戻しなどの場面に自然に遭遇します。

十八、初心者が最も誤解しやすいポイント

1. GitHubへのログインはcommitの身元と同じではない

GitHubへのログインは主にリモートリポジトリのアクセス権を解決します。commit表示名とメールはGitの設定に依存します。

2. Forkはダウンロードではない

Forkは自分のGitHubアカウント配下へのコピーであり、Cloneは自分のPCへのダウンロードです。

3. CommitはPushではない

Commitはローカルでのバージョン保存、PushはGitHubへのアップロードです。

4. StarはForkとは異なる

Starは「お気に入り」、Forkはプロジェクトのコピーです。

5. Pull Requestは必ず受け入れられるとは限らない

PRは元プロジェクトへの変更反映依頼ですが、メンテナーは受理、却下、追加修正要求を自由にできます。

6. GitHub貢献グラフは実力そのものではない

貢献グラフは継続性を示す一指標ですが、エンジニアリング能力を完全に表すものではありません。価値があるのは、プロジェクト品質、文書の明瞭さ、コードの実行可能性、継続的な改善履歴です。

十九、学習順序の提案

ゼロから始めるなら、次の順序で進めるのがおすすめです。

1. まずはリポジトリページの読み方を理解：README、Code、Issues、Pull Requests、Actions 2. 次にRepository、Commit、Branch、Fork、Star、Watchを理解 3. 次に git clone、git status、git add、git commit、git push を習得 4. その後、1週間の実体ある提出を続ける自分用ノートリポジトリを作る 5. 最後にPull Request、オープンソース貢献、GitHub Actionsを学ぶ

最初から複雑な協業を目指す必要はありません。まずは自分のプロジェクトをアップロードし、修正し、コミットし、公開まで通す方が先です。

二十、まとめ

GitHub初心者にとって最重要なのは、最初からすべてのコマンドを押さえることではなく、まずいくつかのコア動作を理解することです。

リポジトリを作成
→ ファイルを修正
→ commitを作成
→ pushする
→ プロジェクトを公開する

他人のプロジェクトに参加したいなら、さらに理解します。

Fork
→ 修正
→ Commit
→ Pull Request

GitHubは本質的には、作品を記録し、能力を示し、オープンソースに参加し、プロジェクトを管理するためのプラットフォームです。AIツールとWeb開発を学ぶ人にとって、GitHubは単なるコード倉庫ではなく、長期的な作品集そのものです。

毎日少しずつ実体ある変更を行い、継続的に記録し、継続的にコミットし、継続的に振り返ることが、短時間で多数の複雑概念を詰め込むことより重要です。

よくある質問

この記事はどのレベルの開発者向けですか？

本文の「対象読者」に関する説明を参照してください。当ブログのプログラミング記事では、入門からAIプログラミングワークフローまでさまざまなレベルを対象にしており、各記事ごとに想定前提が異なります。

この記事のツールやコマンドはOSごとに差がありますか？

あります。macOS、Linux、Windowsではターミナル環境、パス形式、コマンド構文に差があるため、記事で明示されていない場合は該当する公式ドキュメントを参照して調整してください。

どのAIツールを併用して学習するのがおすすめですか？

Claude CodeとCodexは、現在性能が高いプログラミング向けAIツールです。コード解説、ロジック補完、デバッグ、スクリプト生成に利用できます。関連ツールの紹介は、当サイトのCC Switch ツール記事とVibe Coding面接問題集を参考にしてください。

プログラミングで最も大事な習慣は？

実践の方が教材視聴より重要です。まずはできるだけ早く本物のプロジェクト（小さくてもよい）を見つけ、問題が出たらドキュメントとコードを見て解決する習慣をつけてください。理論を最後にまとめる前に、ただ終わらせることが目的化しないように。

参考ソース

• GitHub Docs：Hello World
• GitHub Docs：Changing the default branch
• GitHub Docs：Managing the default branch name for your repositories
• Git Documentation：git-branch
• GitHub Docs：Pull requests documentation
• GitHub Docs：Fork a repository
• GitHub Docs：Profile contributions reference
• GitHub Docs：Understanding GitHub Actions

Gitの基本操作に慣れているなら、次はAIツールをワークフローに組み込む方法を進めると良いです。Vibe Coding / Agentic Flow 面接問題集