GitHubの使い方｜ゼロから始めてプルリクエストまで使える手順を解説

「GitHubは使えた方がいいと聞くけど、何から始めればいいかわからない」

そう感じている方は多いのではないでしょうか。GitHubはコードを管理・共有するための世界標準プラットフォームで、個人開発からチーム開発まで幅広く使われています。

本記事では、特に利用者の多いWindows環境を中心に、Gitのインストールからプルリクエストの作成まで、初心者が迷わず進める手順を図解で解説します。

1. GitHubの使い方を学ぶ前に｜GitとGitHubの違いを理解する

GitHubの使い方を学ぶ前に、まず「GitとGitHubは別のものである」という点を整理しておきましょう。

一言で言えば、Gitはソフトウェア、GitHubはサービスです。この違いを押さえてから操作を始めると、コマンドの意味やデータの流れがスムーズに理解できます。

データの流れはおおまかに次のとおりです。

• ローカル環境での変更は「Worktree（作業ディレクトリ）」に生まれ
• git addで「Index（ステージング）」に仮置きされ
• git commitで「Local Repository」に記録され
• 最後にgit pushで「Remote Repository（GitHub）」に送信されます。

この4段階を頭に入れておくと、各コマンドの役割が自然とわかるようになります。

GitはPCで動くソフト、GitHubはコードを置くクラウドサービス

Gitは、ファイルの変更履歴を記録・管理するためのバージョン管理ソフトウェアです。

インターネット接続なしにローカルPC上で動作し、「いつ・誰が・何を変えたか」を記録し続ける道具です。いわば手元にある「変更履歴専用のメモ帳」といえます。

GitHubは、Gitで管理した変更履歴をクラウド上に保存・共有できるWebサービスです。個人のコードをバックアップしたり、チームメンバーと共同編集したりするための「コードのクラウド倉庫」として機能します。

GitとGitHubの役割の違い

項目	Git	GitHub
種別	ソフトウェア（ローカルで動く）	Webサービス（クラウド上）
主な役割	変更履歴の記録・管理	コードの保存・共有・共同作業
インターネット接続	不要	必要
例え	手元の「変更メモ帳」	その記録を置く「クラウド倉庫」

Gitだけでもバージョン管理は可能ですが、GitHubと組み合わせることで「チームでの共有」「バックアップ」「コードレビュー」といった実務上のメリットが一気に加わります。

GitHubを使いこなすとエンジニアのキャリアにどう影響するか

ファインディ株式会社がCodeZineで発表した調査によると、国内エンジニアのGitHub利用率は約30%にとどまっています。

言い換えれば、GitHubを使いこなせること自体が、現時点では差別化ポイントになり得るということです。

グローバルでは、GitHub Octoverse 2025レポートによると、生成AIプロジェクトが前年比98%増を記録し、TypeScriptが最も使われる言語トップに立ちました。

AI活用が開発のメインストリームになりつつある今、GitHubはその中心インフラとして機能しています。

（出典：CodeZine 、Publickey ）

転職・就職活動への具体的な影響

採用担当者がエンジニア候補を評価する際、GitHubのプロフィールページを参照するケースが増えています。

コントリビューション履歴（いわゆる「草」）や公開リポジトリのコード品質は、履歴書では伝えにくい「実際に手を動かしてきた証拠」として機能します。

GitHubを学ぶことは、技術習得とポートフォリオ構築を同時に進められる、一石二鳥の取り組みです。

2. GitHubの使い方を始める前に｜環境構築の手順を完了させる

GitHubを使い始めるには、まずいくつかの準備ステップが必要です。

1. Gitのインストールと初期設定
2. GitHubアカウントの作成
3. SSH接続の設定

以上の順に進めていきます。

IPAが公表した「2024年度ソフトウェア動向調査」によると、バージョン管理ツールの活用は国内の開発現場で標準的な実践として定着しつつあります。

一度環境構築を済ませれば、その後の操作は格段にスムーズになります。

（出典：IPA ）

GitをインストールしてGitHubと連携するための初期設定を行う

GitはGit公式サイト（https://git-scm.com/）からダウンロードできます。

Windowsの場合

EXEファイルを実行し、デフォルト設定のまま「Next」を押し続けるだけでインストール完了です。

macOSの場合

Homebrewを使ってbrew install gitでインストールするのが一般的です。

インストール後はターミナル（WindowsはGit Bash、macOSはターミナル.app）を開き、以下のコマンドで初期設定を行います。

初期設定コマンド（Windows・Mac共通）

# ユーザー名の設定
git config --global user.name "Your Name"

# メールアドレスの設定（GitHubアカウントと同じアドレス推奨）
git config --global user.email "your.email@example.com"

# 設定の確認
git config --list

user.nameとuser.emailはコミット履歴に記録されます。

GitHubアカウントに登録したものと合わせておきましょう。設定後にgit config --listを実行し、入力した値が表示されれば完了です。

インストール確認コマンド

# バージョンが表示されれば成功
git --version
# 例）git version 2.44.0

GitHubアカウントを作成して無料プランで使い始める

GitHub.com（https://github.com/）にアクセスし、「Sign up」ボタンからアカウントを作成します。

メールアドレス・パスワード・ユーザー名を入力し、認証メールのコードを入力すれば登録完了です。

「有料プランが必要では？」と心配する必要はありません。無料プランで個人開発に必要な機能はほぼすべて揃っています。

なお、利用にあたっては公式の利用規約を遵守し、特に機密情報の誤プッシュなどセキュリティ管理には十分注意してください。

無料プラン（Free）でできること

機能	無料プラン（Free）
パブリックリポジトリ	無制限
プライベートリポジトリ	無制限（コラボレーター制限あり）
GitHub Actions	月2,000分まで無料
GitHub Pages	利用可能

SSHキーを設定してGitHubに安全に接続する

GitHubは2021年8月にパスワード認証によるGit操作を廃止しており、現在はSSH接続が現在の標準となっています。

SSH（Secure Shell）は通信を暗号化してサーバーに安全に接続する仕組みです。一度設定すれば、以降はパスワード入力なしでpush/pullができます。

（出典：GitHub Docs ）

SSH設定の全体フロー

①SSHキーを生成する → ②公開鍵をGitHubに登録する → ③接続確認コマンドで動作確認する、の3ステップで完了します。

①SSHキーの生成（Windows・Mac共通）

# SSHキーの生成（メールアドレスはGitHubに登録したものを使用）
ssh-keygen -t ed25519 -C "your.email@example.com"

# 保存場所はEnterでデフォルトパスに保存
# パスフレーズは任意（設定することを推奨）

②公開鍵の確認とGitHubへの登録

# 公開鍵の内容を表示
cat ~/.ssh/id_ed25519.pub

表示されたssh-ed25519 AAAA...から始まるテキスト全体をコピーし、GitHubの「Settings → SSH and GPG keys → New SSH key」からタイトルを付けて登録します。

③接続確認コマンドと成功時の出力

# 接続確認
ssh -T git@github.com

以下のメッセージが表示されれば、SSH接続の設定は完了です。（※初回接続時は継続の確認を求められることがありますが、yesと入力して進めます）

Hi [username]! You've successfully authenticated, but GitHub does not provide shell access.

[username]が自分のGitHubユーザー名に置き換わっていれば成功です。表示されない場合は、公開鍵のコピーに漏れがないか再確認してください。

3. GitHubの使い方・基本操作｜はじめてのコミットとプッシュを実践する

環境構築が完了したら、いよいよGitHubを実際に操作してみましょう。

押さえるべきコマンドはadd・commit・pushの3つです。それぞれの役割を一言で表すと「ステージング（仮置き）→ スナップショット保存 → クラウドに送信」となります。

GitHubでリモートリポジトリを新規作成する

リモートリポジトリとは、GitHub上に置くコードの「クラウド倉庫」のことです。

GitHubにログインし、画面右上の「＋」アイコンから「New repository」を選択して作成します。

リポジトリ作成時の設定項目

設定項目	選択肢	推奨
Repository name	任意の名前	英数字・ハイフンで簡潔に
Public / Private	Public（公開）/ Private（非公開）	ポートフォリオ目的はPublic、練習はPrivate
Add a README file	チェックあり / なし	初めての場合はチェックありが無難

リポジトリ作成後は、緑色の「Code」ボタン → 「SSH」タブを選択し、表示されているgit@github.com:username/repo-name.git形式のURLをコピーしておきます。

次の手順で使います。

ローカルリポジトリを作成してGitHubのリモートと連携する

ローカルリポジトリとは、自分のPC上に作るGit管理用の作業場所です。新規フォルダにも既存のプロジェクトフォルダにも設定できます。

新規フォルダからGitを初期化して連携する

# 作業フォルダを作成して移動
mkdir my-project
cd my-project

# Gitリポジトリとして初期化
git init

# GitHubのリモートリポジトリと連携（コピーしたSSH URLを使用）
git remote add origin git@github.com:username/repo-name.git

# 連携確認
git remote -v

git remote -vを実行してoriginのURLが表示されれば、ローカルとリモートの連携は完了です。

既存プロジェクトにGitを後から導入する場合

すでに作業中のフォルダがある場合は、そのフォルダに移動してからgit initを実行するだけです。その後のgit remote add originの手順は変わりません。

git add・commit・pushでGitHubにファイルを送る基本の使い方

ファイルの変更をGitHubに反映させるには、add → commit → pushの3ステップを順番に実行します。

3コマンドの役割

コマンド	役割（一言）	例え
git add	変更ファイルをステージングに仮置き	宅配便の箱に荷物を詰める
git commit	ステージングの内容をスナップショットとして保存	箱に送り状（メモ）を貼る
git push	コミット済みの内容をGitHubに送信	箱を配送センター（GitHub）に送り出す

# まず現在の変更状態を確認する習慣をつける
git status

# 変更したファイルをステージングに追加（全ファイルの場合は . を使用）
git add .

# コミット（変更内容を一言で表すメッセージを記述する）
git commit -m "最初のコミット"

# GitHubのmainブランチにプッシュ
git push origin main

成功時に表示される出力例

Branch 'main' set up to track remote branch 'main' from 'origin'.
Everything up-to-date

Everything up-to-dateと表示されれば、変更がGitHub上に正しく反映されています。

プッシュ後はブラウザでリポジトリページを開き、ファイルが反映されているか目視でも確認する習慣をつけておくとよいでしょう。

4. GitHubの使い方・実践編｜ブランチとプルリクエストでチーム開発に参加する

個人開発の流れを掴んだら、次はチーム開発へのステップアップです。

「ブランチを切ってプルリクエストを出せる」というスキルは、就職・転職の選考でもポートフォリオと並んで評価されることが多いです。

このセクションでは、チームのリポジトリを手元に複製するところから始め、ブランチ作成・プッシュ・プルリクエスト・マージ・コンフリクト解決まで、チーム開発の一連のフローを解説します。

git cloneでGitHubのリポジトリをローカルに複製する

チーム開発に参加するとき、最初にすることはチームのリポジトリをローカルに複製することです。

このとき使うコマンドがgit cloneです。第3章で説明したSSH URLのコピー方法（Code → SSH タブ）と同じ手順でURLを取得し、以下を実行します。

# リポジトリをローカルに複製
git clone git@github.com:username/repo-name.git

# 複製されたフォルダに移動
cd repo-name

クローンが完了すると、リポジトリのすべてのファイルと変更履歴がローカルにコピーされます。

git remote add originの設定も自動で完了しているため、すぐにpush/pullできる状態になります。

ブランチを作成・切り替えてGitHubの変更を安全に管理する

ブランチは、メインの作業ラインを壊さずに「実験用の作業コピー」を作る機能です。

チーム開発ではmainブランチを直接変更することは基本的に禁止されており、機能追加・バグ修正ごとに専用のブランチを作って作業するのが現場のルールです。

ブランチ作成と切り替えのコマンド

# 現在のブランチ一覧を確認
git branch

# ブランチ作成と切り替えを同時に行う
git switch -c feature/login-form

ブランチ命名の例

種類	命名例
機能追加	feature/login-form
バグ修正	fix/null-pointer-error
リファクタリング	refactor/api-client

ブランチ名はチームのルールに従うのが最優先ですが、上記のようなprefixを使う命名は多くの現場で採用されています。

変更をプッシュしてGitHub上でプルリクエストを作成する

ブランチ上での作業が完了したら、GitHubにプッシュしてプルリクエスト（PR）を作成し、チームにレビューを依頼します。

ブランチへのプッシュ

# 変更をステージングに追加してコミット
git add .
git commit -m "ログインフォームのバリデーションを追加"

# 作業ブランチをGitHubにプッシュ
git push origin feature/login-form

プッシュ後にGitHubのリポジトリページを開くと、「Compare & pull request」ボタンが表示されます。クリックするとPR作成画面に遷移します。

PR説明文に書くべき内容

• 変更内容：何を変更したか（例：「ログインフォームに入力バリデーションを追加した」）
• 変更理由：なぜ変更したか（例：「未入力のままAPIリクエストが飛ぶバグを防ぐため」）
• 確認方法：レビュワーが何を確認すればよいか（例：「空欄送信時にエラーメッセージが表示されるか確認してください」）

PRはコードの変更を届けるだけでなく、「このコードをどう見てほしいか」をチームに伝えるコミュニケーションの場でもあります。

丁寧な説明文がチーム全体の開発効率を高めます。

レビュー後にGitHubでマージしてブランチを削除する

レビュアーの承認（Approve）が得られたら、PRをマージして変更をmainブランチに取り込みます。GitHubのPR画面からマージ方式を選択できます。

マージ方式の比較

マージ方式	特徴	適した場面
Merge commit（推奨）	ブランチの履歴を保持しつつマージコミットを作成	入門段階・履歴を残したい場合
Squash and merge	複数コミットを1つにまとめてマージ	コミット履歴をすっきりさせたい場合
Rebase and merge	コミットをmainの先頭に並べ直してマージ	線形な履歴を保ちたい上級者向け

入門段階ではMerge commitがおすすめです。変更の経緯が履歴として残るため、後から「どのブランチでいつ何をしたか」を追いやすくなります。

マージ後のブランチ削除（後片付け）

# mainブランチに切り替えて最新状態に更新
git switch main
git pull origin main

# 不要になったブランチを削除
git branch -d feature/login-form

マージ済みのブランチはGitHub上の「Delete branch」ボタンからも削除できます。

不要なブランチを残しておくとリポジトリが散らかるため、マージ後の削除を習慣にしておきましょう。

コンフリクトが起きてもGitHubの使い方を止めないための解決手順

コンフリクト（競合）とは、複数人が同じファイルの同じ箇所を別々に変更したとき、Gitがどちらを採用すべきか判断できない状態のことです。

難しそうに聞こえますが、コンフリクトはGitが衝突箇所を検知してくれているサインです。落ち着いて以下の手順で対処すれば問題ありません。

コンフリクトが発生したファイルの表示例

<<<<<<< HEAD
現在のブランチの内容（自分の変更）
=======
マージしようとしているブランチの内容（相手の変更）
>>>>>>> feature/login-form

コンフリクト解決の3ステップ

ステップ	操作内容
①コンフリクト箇所を特定	git statusでコンフリクト中のファイルを確認
②ファイルを手動編集	<<<<<<<〜>>>>>>>の記号ごと削除し、残す内容だけに整える
③再コミット	編集後にgit addとgit commitを実行

# コンフリクト解決後の再コミット
git add .
git commit -m "コンフリクトを解決"
git push origin feature/login-form

エディタを使った視覚的な解決方法

VSCodeなどのエディタを使うと、コンフリクト箇所がハイライト表示され「Accept Current Change / Accept Incoming Change」ボタンで視覚的に選択できます。

コマンドラインに不慣れな場合はエディタの補助機能を活用するのがおすすめです。

5. GitHubの使い方・応用編｜CopilotやActionsで開発効率を上げる

基本操作を習得したら、GitHub CopilotとGitHub Actionsという2つの応用ツールを紹介します。

GitHub Octoverse 2025によると、生成AIプロジェクトは前年比98%増を記録し、TypeScriptが最も使われる言語トップに立っています。概要と導入の入り口を押さえておきましょう。

（出典：Publickey ）

GitHub Copilotを使い始めてAIにコード補完・生成を任せる

GitHub Copilotは、GitHubとOpenAIが共同開発したAIコーディング支援ツールです。コメントや関数名を入力するだけで、次のコードを自動補完・生成してくれます。

GitHub Copilotの主な機能と無料枠

項目	内容
無料枠（Copilot Free）	月2,000回のコード補完、月50回のチャット利用が可能
対応エディタ	VSCode、JetBrains系、Vimなど主要エディタ
主な用途	コード補完、テストコード生成、コメントからの関数生成

VSCodeへの導入手順（概要）

VSCodeの拡張機能マーケットプレースで「GitHub Copilot」を検索してインストールし、GitHubアカウントでサインインするだけで使い始められます。

コーディングスピードの向上も期待できますが、特に実務で注目したいのがレビュー負荷の軽減です。

テストコードや定型的なコードをAIが生成することで、人間のレビュアーはロジックの正確性に集中できるようになります。詳細は関連記事「GitHub Copilot 使い方」を参照してください。

GitHub Actionsの使い方でテストとデプロイを自動化する

GitHub Actionsは、コードをpushしたら自動でテストが走る仕組み（CI/CD）をGitHub上で設定・実行できる機能です。

リポジトリ内に.github/workflows/フォルダを作成し、YAMLファイルを置くだけで動作します。

最小構成のYAMLサンプル（Node.jsのテスト自動化例）

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

このYAMLを.github/workflows/ci.ymlとして保存すると、mainブランチへのpushやPR作成時に自動でテストが実行されます。

テストが失敗した場合はGitHub上で赤いバッジが表示され、マージ前に問題を検知できます。

CI/CDを導入することで得られる主なメリット

• テスト漏れによるバグの本番流出を防げる
• 手動デプロイ作業を省力化できる
• レビュアーが「動くかどうか」ではなく「コードの品質」に集中できる

詳細は関連記事「GitHub Actions 入門」を参照してください。

GitHubのプロフィールをポートフォリオとして転職・就職に活用する

GitHubのプロフィールページは、エンジニアにとって「動くポートフォリオ」として機能します。採用担当者が注目するポイントは主に3つです。

採用担当者が注目するGitHubプロフィールの要素

要素	内容と効果
コントリビューション履歴（草）	継続的に開発しているかが一目でわかる。毎日緑が埋まっていると「習慣的に手を動かしているエンジニア」として評価されやすい
プロフィールREADME	自己紹介・使用技術・連絡先などを記載できる。GitHubユーザー名と同名のリポジトリにREADME.mdを置くと自動でプロフィールに表示される
Pinnedリポジトリ	最大6つのリポジトリをプロフィールに固定表示できる。自信のある成果物をピン留めしておくと、訪問者の目に留まりやすくなる

GitHubを使い続けること自体が、継続的な学習の証明になります。「何か特別なものを作らなければ」と構える必要はなく、本記事の手順を実践して小さなプロジェクトやコード練習の履歴を積み重ねるだけでも、十分に評価の対象になります。

6. まとめ｜GitHubの使い方はゼロから段階的に習得できる

GitHubは一日で全機能を使いこなす必要はありません。

まずSSH接続を完了させ、最初のpushを成功させることが最初の大きな一歩です。その先にブランチ管理・プルリクエスト・CI/CDへの道が続いています。

概念を理解しながら手を動かすことで、一つひとつの操作の意味が自然と身についていきます。本記事の手順を一つひとつ、焦らず進めてみてください。