MENU
AI×データの技術情報メディア
  1. ホーム
  2. データ基盤・ツール
  3. GitHubとは？初心者の使い方・初期設定からadd・push・プルリクエストまで解説

GitHubとは？初心者の使い方・初期設定からadd・push・プルリクエストまで解説

データ基盤・ツール
GitHubとは？初心者の使い方・初期設定からadd・push・プルリクエストまで解説

「GitHub（ギットハブ）ってGitと何が違うの？」「アカウントを作った後、最初は何をすればいいの？」「add・commit・pushやプルリクの流れが覚えられない」

GitHubとは、Gitのリポジトリをクラウドでホストし、計画・レビュー・テスト・展開・運用などの協業機能を追加したプラットフォームです。

最終確認日：2026年10月3日。本記事の仕様・手順・料金・プラン名は、特記がない限りdocs.github.com・github.blog・git-scm.com・github.comの一次情報（確認日時点）に基づきます。仕様と料金は変更されるため、導入・運用前に公式ドキュメントで最新を確認してください。表の「【編集部整理】」「【例】」とある箇所は、一次情報をもとにした編集部の整理・例示です。

この記事でわかること
  • GitとGitHubの違いと、取得→編集→記録→共有の全体像5段階
  • アカウント作成・Git導入・user.name／email設定・リポジトリ作成の準備手順
  • clone→add・commit・pushの基本操作と、確認の癖（status／diff）
  • ブランチ・プルリクエスト・マージの最小実践フロー
  • HTTPS／SSH・PAT・2FAなどの認証と、公開範囲・秘密情報の安全策
  • pushできないとき・コンフリクト時の確認順序と対処の考え方
  • 料金の考え方と、VS Code・Desktop・CLIの3ルートの選び方
  • データ分析プロジェクトでの使い方と、AI分業時代の確認ポイント
目次

要点（この記事の結論）

  • Gitは変更を追跡する分散型バージョン管理システム、GitHubはそのホスティングに協業機能を加えたものです。まずこの区別を押さえます
  • 最小完走は「リポジトリ作成→clone→編集→statusで確認→add→commit→push」です。いきなり応用を触らず、この順で1周させます
  • addはステージング、commitは履歴への保存、pushはリモートへの反映です。3つを混同しないことが基本です
  • チーム開発は「switch -cでブランチ作成→push→プルリクエスト作成→レビュー→マージ→pull」が基本です。既定ブランチは新規ではmainです
  • Git操作のパスワード認証は2021年8月13日に廃止されました。HTTPSならPAT（Personal Access Token、個人用アクセストークン）＋認証情報保持、SSHならed25519鍵＋登録が2026年時点で推奨される方法です
  • 秘密情報はコミットしない、学習用はPrivateから始めるのが安全です。push保護で止められた場合の直し方は決まっています
  • 無料範囲・入口（VS Code／Desktop／CLI）は時点と公式誘導を添えて判断します。数値の断定はしません
  • データ職ではREADME・.gitignore・小さなプルリクエストを徹底します。AIに任せる場合も人間が差分と説明文を確認します

GitHubとは？Gitとの違い・全体像

ここがポイント

初めての方は、まず「取得→編集→記録→共有」の5段階だけ覚えてください。Gitが記録の仕組み、GitHubが置き場＋進め方と覚えると整理しやすいです。

GitHubは、ソフトウェア開発ライフサイクル（SDLC）の全段階を支援するプラットフォームと説明されています。原文ではPlan／Create／Review／Test／展開／Operateが挙げられています。

初めての方は、まず「取得→編集→記録→共有」の5段階だけ覚えてください。

  • 取得：cloneでリモートの複製を手元に持ってくる
  • 編集：ファイルを直す
  • 記録：add・commitで履歴に残す
  • 共有：pushでリモートに送る
  • 合流：プルリクエストでレビューしてマージする

この流れが回ると、個人作業もチーム開発も同じ型で進められます。

GitとGitHubの違い

Git（ギット）は、ファイルへの変更を追跡するバージョン管理システム（VCS）です。独自コピーで作業し、変更履歴を記録し、他者の変更と安全にマージできます。

GitHubは、Gitプロジェクト（リポジトリ）をクラウドでホストし、計画・コラボレーションツールを追加したものと説明されています。Issueやプルリクエスト、レビュー、Marketplaceなどの協業層が乗っている点が特徴です。

観点 Git GitHub
定義 変更を追跡する分散型VCS。全履歴のコピーを各自が持ち、中央接続なしで作業できる Gitホスティング＋Issue・プルリクエスト・レビューなどの協業機能
動く場所 ローカル中心。ホストを問わず使える クラウド中心。Gitリポジトリに変更（コミット）すると追跡・管理が始まる
操作コマンド gitはローカル／リモートのGitリポジトリ操作用 gh（GitHub CLI）はGitHub操作専用
覚え方 記録の仕組み 置き場＋進め方

【編集部整理】Gitが「ノートの取り方」なら、GitHubは「ノートを置いて皆で見る図書館と会議室」です。用語は次の4つを押さえると読み進めやすいです。

用語 意味
リポジトリ 変更履歴を保存するフォルダー
コミット 時点のスナップショット。写真に例えられます
ブランチ プロジェクトのコピー。並行作業の単位です
プルリクエスト（プルリク） ブランチ間のマージ要求。レビューの場になります

初出のため補足します。プルリクエストは本記事では略してプルリクとも書きます。プッシュはリモートへ送ること、マージは取り込むことです。

全体像5段階（clone→編集→add／commit→push→プルリク）

公式チュートリアル「Hello World」で学べる4要素は、リポジトリ作成、ブランチ開始・管理、変更→コミット、プルリクエストのオープン・マージです。本記事では、最初にcloneを足した5段階で整理します。

段階 やること コマンド・操作の例
1．取得 リモートの複製を手元に作る git clone、gh repo clone
2．編集 ファイルを直す。ブラウザ直接操作も可だが、多くはローカル作業→リモート同期 エディタで編集
3．記録 変更をステージして履歴に残す。確認の癖が大切 git status、git add、git commit
4．共有 ローカルのコミットでリモートを更新する git push
5．合流 ブランチをレビューして取り込む プルリクエスト作成→マージ

ブラウザのみでもHello World演習は完走できます。readme-editsブランチ作成→README編集→Commit changes→New pull request→Compare→Create→Merge pull request→Confirm merge→Delete branchの順です。

コマンドに慣れないうちは、このブラウザ完走で全体像をつかむ方法もおすすめです。詳しい連携の考え方は、LinearとはのGitHub連携節と合わせて読むと、Issueとプルリクの関係が整理しやすいです。

全体5段階を図にすると次の通りです。

GitHub 使い方 全体 clone add commit push PR 流れ 図
図：基本操作の全体5段階（編集部作成・2026年10月04日時点）

GitHubを始める前の準備｜アカウント・インストール・初期設定

準備は「アカウント作成→Git導入→名前・メール設定→リポジトリ作成」の順です。ここを飛ばすとpush時の認証やコミット表示でつまずきます。

公式のSet up Git概要でも、1．Gitインストール、2．user.name設定、3．コミットメール設定の順で案内されています。

アカウント作成とリポジトリ作成

アカウント作成画面の年齢制限やプラン選択、メール検証の必須順序について、一次情報での確認は取れていません。申し込みは次の公式起点から進め、手順は画面表示に従ってください。

リポジトリ作成（Web）の手順は公式に記載があります。

  1. 右上の＋→New repositoryを選ぶ
  2. Owner（所有者）を選択する
  3. 名前を付ける。説明は任意です
  4. 公開範囲（Public／Private）を選択する
  5. Add READMEをオンにする
  6. Create repositoryを選ぶ

作成時の任意項目の意味は次の通りです。既存リポジトリのインポート時は、競合回避のため選ばないことが推奨されています。

項目 意味
README プロジェクト説明文書。README.mdとして置きます
.gitignore コミット除外の無視ルール一式
license（ライセンス） 利用条件を示す文書。LICENSEとして置きます

CLIで作る場合は、次のコマンドが使えます。

# 対話形式で作成する
gh repo create
# 名前を指定してPublicで作る例
gh repo create project-name --public
# 作成と同時にcloneまで行う例
gh repo create project-name --public --clone

--public／--private／--internalフラグで公開範囲を指定できます。--internalはEnterprise向けです。

公開範囲の定義は次の通りです。

公開範囲 意味
Public インターネット上の全員がアクセスできます
Private 自分・明示共有者・Orgでは一部メンバーのみが対象です

学習中の非公開メモや秘密情報を含む可能性がある場合は、Privateから始めるのが安全です。

リポジトリ新規作成画面の例（公式Docsより）は次の通りです。

GitHub リポジトリ新規作成 Repository name画面
出典：GitHub Docs「Quickstart for repositories」（2026年10月04日時点）

Gitの導入と初期設定

Windows／Mac別のインストーラや、winget・brewなどの具体コマンドについて、一次ソースは未取得です。本記事では手順を断定しません。公式のSet up Git起点で、お使いのOS向け手順を確認してください。OS別の画面操作は公式Set up GitページのOS切替タブで確認してください。

導入後に必ず行うのが、コミット作者の名前とメール設定です。Gitのユーザー名（Git username）はGitHubのユーザー名とは別物です。設定は将来のコミットのみに影響します。

# すべてのリポジトリに適用する例
git config --global user.name "Mona Lisa"
# 単一リポジトリだけに適用する例（--globalなし）
git config user.name "Mona Lisa"

メールも同様です。GitHub提供のnoreplyアドレスでも、任意のアドレスでも設定できます。

# すべてのリポジトリに適用する例
git config --global user.email "YOUR_EMAIL"
# 単一リポジトリだけに適用する例
git config user.email "YOUR_EMAIL"
# 設定の確認
git config user.email

まずは小さな練習リポジトリを1つ作り、READMEあり・Privateで始めてみてください。次の章の5コマンドを回す土台になります。

基本操作は？add・commit・pushと確認の癖

基本操作は「clone→編集→status／diffで確認→add→commit→push」の順です。add・commit・pushの3段階を区別できると、混同が減ります。

clone→編集→status／diffで確認

git cloneは、既存リモートの複製を作る操作です。ファイル・履歴・ブランチを含みます。git statusは、untracked（未追跡）・modified（変更あり）・staged（ステージ済み）の状態を表示します。

clone手順は次の通りです。Codeボタン→HTTPS／SSH／GitHub CLIのURLコピー→コマンド実行の順です。

# HTTPSの例（YOUR-USERNAME・YOUR-REPOSITORYは置き換え）
git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
# GitHub CLIの例（OWNER/REPO形式。OWNER省略時は認証ユーザー）
gh repo clone OWNER/REPO

リモートURL形式は次の2通りです。

方式 URL例 補足
HTTPS https://github.com/user/repo.git` ファイアウォール・プロキシ配下でも利用できます
SSH git@github.com:user/repo.git 鍵ペアの生成・登録が必須です

編集後は、いきなりaddせずgit statusで状態を見ます。差分の中身を見たいときはgit diffも使います。この「確認の癖」が、意図しないファイルの混入を防ぎます。

既存リポジトリへの貢献例として、公式では次の流れが示されています。そのまま置き換えて使えます。

git clone https://github.com/owner/repo.git
cd repo
git branch my-branch
git checkout my-branch
# ここで編集する
git add file1.md file2.md
git commit -m "my snapshot"
git push --set-upstream origin my-branch

clone時のURL取得画面の例（公式Docsより）は次の通りです。

GitHub clone HTTPS URL Codeボタン
出典：GitHub Docs「Cloning a repository」（2026年10月04日時点）

add・commit・pushの違いと使い分け

公式の定義を整理すると、次の通りです。【編集部整理】

コマンド 意味 例え
git add 変更のステージング。記録対象に載せる前半作業 カゴに入れる
git commit スナップショットを履歴に保存する 写真を撮る
git push ローカルのコミットでリモートを更新する アルバムを共有棚に送る
git pull リモート追跡ブランチでローカルを更新する 棚の最新を受け取る
git status 状態表示。確認の起点 現在地確認

混同しやすい3パターンです。

  • addしただけでcommitした気になる→git statusでstaged止まりを確認します
  • commitしただけでpushした気になる→リモートに反映されません。git pushが必要です
  • pullとpushを逆に覚える→pullは受け取り、pushは送り出しです

Web編集時は、Commit message入力→ブランチ選択→Propose changesの順で進みます。ローカルとWebで呼び名が少し違いますが、やっていることは同じ記録作業です。

add・commit・pushの違いを図にすると次の通りです。

Git add commit push 違い 図
図：add・commit・pushの違い（編集部作成・2026年10月04日時点）

いつもの5コマンド反復表

公式の頻出ループは、git add .→git commit -m "Describe your change"→git push --set-upstream origin YOUR-BRANCH-NAMEです。新規公開時は、リモート追加から行います。

# 新規公開の例（YOUR-USERNAME・YOUR-REPOSITORY-NAMEは置き換え）
git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git
git push --set-upstream origin main

push形式はgit push REMOTE-NAME BRANCH-NAMEです。例としてgit push origin mainが示されています。cloneした自分のリポジトリは、remote URLがfetch／push先になります。

反復用の5コマンド表です。練習リポジトリでこの順に回してください。

順番 コマンド 目的
1 git clone 初回のみ。取得する
2 git status 毎回。状態を確認する
3 git add またはgit add . 記録対象に載せる
4 git commit -m "変更内容" 履歴に保存する
5 git push origin リモートに反映する。初回は--set-upstream付き

まずはREADMEの1行修正で5つを回すのがおすすめです。小さく回すほど、どこで止まったか切り分けしやすいです。

ブランチ・プルリク・マージの最小実践は？

チーム開発の最小実践は「ブランチ作成→push→プルリクエスト作成→レビュー→マージ→pull」です。直接mainを触らず、ブランチで作業します。

ブランチは、既存ブランチから作成するのが原則です。通常は既定ブランチ（default branch）から作ります。既定ブランチは、訪問時表示・clone時checkout・プルリクエストやコミットのbase既定になります。作成・プルリクエストオープン・削除・復元にはwrite権限が必要です。

新規リポジトリの既定ブランチ名はmainです。2020年10月1日に変更されました。対象は未設定のユーザー・Org・Enterpriseです。既存リポジトリは影響ありません。既存ブランチ名の変更をWebで行う対応は、2021年1月19日に追加されました。masterは旧既定ブランチ名として扱います。

混在で迷ったら、まず既定がmainかmasterかを確認してください。

ブランチで作業する

ブランチ作成・切替コマンドは次の通りです。新規作成して切り替える場合は、git switch -cを使います。旧式のgit checkout -bと同じ一括操作です。Git 2.23以降はswitch推奨とされています。

# 新規作成して切り替える（一括）
git switch -c new-branch
# 既存ブランチへ切り替える例
git switch testing-branch

作業イメージは次の通りです。

  1. git switch -c fix-typoでブランチを作る
  2. ファイルを編集する
  3. git add→git commitで記録する
  4. git push --set-upstream origin fix-typoでリモートに送る

ブランチ名は内容が分かる短い名前がおすすめです。Issue管理と組み合わせる場合は、LinearとはのGitHub連携節の運用例にあるfix/ENG-123-null-rateのようなID入り命名も参考になります。【例】

プルリク作成からマージまで

プルリクエスト作成（Web）の手順は次の通りです。

  1. Branchメニューで作業ブランチを選択する
  2. Compare & pull requestを選ぶ
  3. base（適用先）とcompare（適用内容）を選択する。既定のbaseは親の既定ブランチです
  4. タイトル・説明を書く
  5. Create Pull Requestを選ぶ。下書きならDraftにします

プルリクエスト作成ボタンの表示例（公式Docsより）は次の通りです。

GitHub Compare pull requestボタン
出典：GitHub Docs「Creating a pull request」（2026年10月04日時点）

プルリクエストの最短路は、ブランチ作成→変更・コミット→プルリクエストオープン→フィードバック対応→マージ→ headブランチ削除（任意）です。同ブランチへの追加コミットは自動反映されます。CLIでは次のコマンドが使えます。

# 作成（--base/--headで方向指定可）
gh pr create
# マージ例（squash＋本文＋ブランチ削除）
gh pr merge 523 --squash --body "my squash commit" --delete-branch

マージ方法は3種です。プルリクエスト下部で方式選択→Confirmの順で進めます。

方式 意味
Merge pull request 全コミットをbaseにマージする
Squash and merge コミットを1つにまとめて取り込む
Rebase and merge rebaseして取り込む

どの方式にするかはチーム方針で決めます。小さく集中的なプルリク・頻繁な小コミット・baseへの頻繁な追従が、レビュー品質の公式推奨です。マージ後はローカルをgit pullで最新にすると、次の作業が始めやすいです。

ブランチ・プルリク・マージの関係を図にすると次の通りです。

GitHub ブランチ プルリク マージ 関係 図
図：ブランチ・プルリク・マージの関係（編集部作成・2026年10月04日時点）

GitHubの認証と安全策｜HTTPS／PAT・SSH・公開範囲

ここがポイント

2026年時点で推奨される方法は「SSHならed25519鍵＋2FA、HTTPSならPAT＋認証情報保持」です。パスワード認証は使えません。

2026年時点で推奨される方法は「SSHならed25519鍵＋2FA、HTTPSならPAT＋認証情報保持」です。パスワード認証は使えません。

Git操作のパスワード認証は、2021年8月13日9時00分（PST）に廃止されました。以降はトークン（PAT／OAuth／GitHub App）またはSSHキーが必要です。

コマンドラインの認証方式は、clone時のリモートURLで決まります。HTTPSかSSHかで必要な準備が変わります。

HTTPSとSSHの選び方

観点 HTTPS SSH
使える範囲 全リポジトリで利用可。ファイアウォール・プロキシ配下でも利用可 ファイアウォール・プロキシで拒否される場合あり
必要なもの（CLIなし） PAT必須。Password欄にPATを入力する。PATはHTTPS専用で、SSHリモートには切替が必要 鍵ペア生成＋GitHub登録が必須
必要なもの（CLIあり） gh auth loginでHTTPS＋Y→Git認証情報自動保存 鍵検出→選択／生成→アップロードをCLIが案内
向き不向き 社内網や制限の厳しい環境でもつなぎたい場合 鍵で手軽に管理したい場合

SSH鍵生成（推奨）は次のコマンドです。レガシー環境のみRSAを使います。

# 推奨（ed25519）
ssh-keygen -t ed25519 -C "your_email@example.com"
# レガシーのみ
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

手順は、保存先は既定でEnter→passphrase設定→ssh-agent追加→GitHubのSettings→SSH and GPG keys→New SSH keyの順です。接続確認の詳細は公式手順で確認してください。

PATは2種あります。fine-grained推奨／classicです。接頭辞で見分けます。

種別 接頭辞 補足
fine-grained github_pat_ 細かい権限推奨
classic ghp_ アクセス可能な全リポジトリに効くため最小権限・有効期限推奨。1年未使用は自動削除

HTTPSのclone例と入力方法です。

git clone https://github.com/USERNAME/REPO.git

Username欄にユーザー名、Password欄にPATを入力します。コマンドラインからリポジトリ操作するclassicの例では、repoスコープ選択が示されています。

毎回入力を避けるには、GitHub CLI（gh auth loginでHTTPS＋Y）またはGit Credential Manager（GCM）がOAuth＋2FAを代行します。SSHはpassphrase付き鍵をssh-agentに保持します。

# 認証情報の対話設定
gh auth login

2FAは、2023年3月13日からコード貢献者への義務化ロールアウトが開始されました。2023年末までに全貢献者が対象と説明されています。対象者は45日前に通知されます。期限後は初回アクセス時に必須です（1日1回・最大1週間snooze可）。28日後にcheck-upがあります。まずは2FAを有効化してから鍵・トークンを整えるのが安全です。

公開範囲と秘密情報の注意

公開範囲の定義は「始める前の準備」の定義表を参照してください。学習・秘密情報ありはPrivate推奨です。

秘密情報はコミットしないことが原則です。push保護（push protection）により、secret検出pushはブロックされます。直し方は検出箇所で変わります。

状況 直し方
直近コミット由来 git commit --amend --all→git push
過去コミット由来 git rebase -i ~1でedit→修正→git add .→git commit --amend→git rebase --continue→git push
誤検出などのバイパス URL先で理由選択（テスト／誤検出／後で修正）→3時間以内に再push

Pythonの分析プロジェクトでは、.gitignoreで除外指定します。リポジトリrootの.gitignoreで指定し、公式推奨集はgithub/gitignore公開リポジトリにあります。共有したくないローカルのみは.git/info/exclude、全リポジトリ共通は~/.config/git/ignoreを使います。

公式Pythonテンプレの抜粋です。全文転載は避け、要点のみ載せます。

__pycache__/
*.py[codz]
build/
dist/
*.egg-info/
.venv
venv/
env/
.env
.ipynb_checkpoints
coverage.xml
.pytest_cache/

.envや認証ファイル、データの生ファイルは上げない癖を付けると事故が減ります。大容量データの置き場設計はDWH設計の基礎と実践の粒度・置き場設計が参考になります。BI側の見せ方を整える場合はPower BIの使い方を参照し、置き場と公開範囲を分けて考えてください。

つまずき対処は？pushできない・コンフリクト

つまずきは「確認順序」で切り分けると見通しが立ちます。【編集部整理】闇雲にコマンドを足さず、状態→認証→権限→ブランチの順に確認すると切り分けしやすいです。

具体的エラーメッセージ原文（例：remote origin already existsなど）や、git remote -v／add／set-urlの公式手順は今回未取得です。該当エラーが出た場合は、メッセージ全文で公式Troubleshootingを検索してください。README競合の再現手順も一次で未取得のため、本記事では概要と公式誘導に留めます。

pushできないときの確認順序

認証失敗の切り分けとして、無トークン・権限不足は404／403、無効資格は401と説明されています（REST API文書の説明。Git操作時の切り分けの目安として転用）。classicがOrgで無効化されていると403になります。HTTPS認証情報がキャッシュ済みだとプロンプトが出ないため、Keychain・資格情報の更新が必要です。

clone失敗時の公式チェックリストは次の3点です。push時にも同じ視点で確認できます。なお原文はclone文脈の記載です。

  • HTTPSで接続できるか
  • 対象リポジトリへの権限があるか
  • 既定ブランチが存在するか

確認順序の例（上の公式3点をpush時に応用した順序）です。

  1. git statusでブランチと未push分を確認する
  2. HTTPSかSSHか、リモートURL形式を確認する
  3. PAT利用か・期限切れや権限不足がないか確認する。Password欄に通常パスワードを入れていないか見直す
  4. Org制限やキャッシュ済み資格情報を確認する
  5. 既定ブランチ名（main／master）の混在を確認する
  6. 初期化あり／なしのREADME競合が疑われる場合は、pull・マージ方針を含め公式手順で確認する

個別エラーメッセージの原文は未確認のため、断定しません。403が出たら「PAT未使用・権限不足・キャッシュ資格・Org制限・既定ブランチ不存在」を順に疑うと切り分けしやすいです。

コンフリクトの直し方（概要・詳細は公式誘導）

競合の定義は、同一行への競合変更、または片方が編集・片方が削除したファイルで発生するものです。プルリクエストで競合があるとGitHubが警告し、解消までマージできません。

行競合の解消手順（概要）は次の通りです。詳細は公式手順で確認してください。

  1. git statusでunmerged filesを確認する
  2. <<<<<<< HEAD／=======／>>>>>>> BRANCH-NAMEを検索する
  3. 残す／統合を決めてマーカーを削除する
  4. git add .する
  5. git commit -m "Resolve merge conflict by incorporating both suggestions"する
  6. push／プルリクのマージに進む

削除・編集競合の考え方です。

# 残すならadd
git add README.md
# 消すならrm
git rm README.md

その後に次のコミットで区切ります。

git commit -m "Resolve merge conflict by keeping README.md file"

競合解消の詳細コマンドや分岐条件は公式ドキュメントの更新を確認してください。無理に一人で解消せず、相手ブランチの作者に意図を聞くのも大切です。

料金・入口・使い分けは？

料金・無料枠は変動しやすいため、本記事では数値の断定を避け、「2026年10月3日時点」の公式表記＋公式誘導で記載します。導入前に必ず次の2つで最新を確認してください。

無料でどこまでできるか

GitHub Free（個人）は、2026年10月3日時点の公式表記では$0／月とされています。publicはフル機能・無制限コラボレーター、privateは限定機能で無制限と説明されています。含まれるものとして、Community SupportとDependabot alertsがあります。Packages 500MB、Codespaces 120 core-hours／月＋15GB／月、Actions 2,000分／月も含まれます。Pagesはpublicリポジトリと記載があります。

GitHub Free（Org）は、2026年10月3日時点の公式表記では上記に加え、チームアクセス制御、Actions 2,000分／月と説明されています。publicのActions・自前ランナーは無料、privateはプラン割当超過で課金とされています。

2026年10月3日時点の公式表記では、次の通りと記載があります。

  • GitHub Pro追加分：メールサポート、Actions 3,000分／月、Packages 2GB、Codespaces 180h＋20GB、privateでPages・Wiki・保護ブランチ等
  • GitHub Team：pricing表示で$4／user／月（初年度割引表記あり）、Actions 3,000分／月、Packages 2GB
  • Enterprise：$21／user／月〜、Actions 50,000分／月、Packages 50GB

いずれも金額・分数・容量は変動しやすいため、本記事では断定しません。「2026年10月3日時点の表示」として捉え、契約前に公式料金表で確認してください。Actions分数・Pages可否・ストレージの適用条件についても、private／public条件を含め公式誘導を優先します。

自分に合う入口の選び方

入口は3ルートです。Visual Studio Code（略 VS Code）・Desktop・CLIの比較表で選んでください。VS Code＋GitHubの詳細手順（拡張機能名・バージョン別操作）は一次で未取得のため、本記事では概要と公式誘導に留めます。

ルート 特徴 向いている人
VS Code Source ControlのPRアイコン→ローカル／リモートブランチ確認→タイトル・説明入力でPR作成（公式Docsのプルリク作成手順を参照） 普段VS Codeで書く人。編集とPRを往復したい場合
GitHub Desktop 無料・オープンソース、Win／Mac対応。GUIでGit操作を可視化、ブラウザなしで認証・PR checkout可。典型フローはDesktopでclone＋branch→VS Code等で編集→Desktopでcommit＋push コマンドなしで使いたい人。可視化して覚えたい場合
GitHub CLI（gh） gh auth login→ホスト選択→画面指示。HTTPS＋YでGit認証情報を自動保存しgit push／pullが楽に。gh repo clone OWNER/REPO、gh repo create、gh pr create／mergeが使える ターミナル中心の人。定型を自動化したい場合

GitHub Desktopは、コマンドなしで使えますかという質問への答えになります。無料・Win／Macで、clone・branch・commit・push・PR checkoutをGUIで実施できます。

CLIの開始例です。

# ホスト選択など画面指示に従う
gh auth login
# clone例
gh repo clone OWNER/REPO

Public／Privateの使い分け判断は次の通りです。

使い分け 選び方
Public 公開してよい学習成果・OSS・ポートフォリオ
Private 秘密情報・社内データ・学習メモの初期置き場

まずはPrivate＋DesktopまたはVS Codeで小さく回し、慣れたらCLIやPublic発信に広げると無理がありません。

データ分析プロジェクトでの使い方・AI分業

データ職の最小ループは「READMEで目的明示→.gitignoreで除外→小さなブランチ→小さなプルリク→レビュー」です。公式のレビュー推奨（小さく集中的なプルリク、頻繁な小コミット、baseへの頻繁な追従）をそのまま当てはめます。

データ職の最小ループ例

Python分析プロジェクトの例です。【例】

置き場 入れるもの 例
README.md 目的・データ出所・再現手順 「売上集計の月次更新。実行順と期待件数を記載」
.gitignore 除外ルール .env、.venv、__pycache__/、.ipynb_checkpoints
分析コード 小さく分けたスクリプト・ノート 前処理・集計・可視化を分ける
大容量 直接載せない。LFS一言メモで方針決定 5GB超は拒否されるため置き場を分ける

Git LFSは、ポインタファイルで大容量を参照管理する仕組みです。最大ファイルはFree／Proで2GB、Teamで4GB、Enterprise Cloudで5GBと説明されています。5GB超は拒否されます。Pages・テンプレートリポジトリではLFS不可とされています。課金・帯域の詳細は公式誘導で確認してください。

プルリク説明文テンプレの例です。【例】three-dot diff（merge base vs topic先端）で「何を持ち込むか」に焦点を当てる考え方に沿っています。

## 目的
- NULL率の集計ロジック修正（対象テーブル：orders）
## 変更点
- 集計SQLの条件修正、前処理の欠損補完を追加
## 確認観点
- [ ] 実行が通ること
- [ ] 件数・NULL率の前後比較を添付したこと
- [ ] .envや生データを含めていないこと
## 影響範囲
- 月次レポートのみ。既定ブランチへの追従済み

Notebookを使う場合も、出力差分が大きくなりがちです。実行結果の取り扱いをチームで決め、小さなプルリクに割るとレビューしやすいです。

AI分業での確認ポイント

Copilotの無料枠・モデル・クレジット制度は流動的です。本記事では条件付き記述に留め、数値の断定はしません。2026年10月3日時点の公式表記では、Copilot Freeは無料・月2,000 completionsまで・自動モデル選択のみ・AIクレジットallowance制、Pro $10／月〜、Pro+ $39／月、Max $100／月（変動大）とされています。機能詳細は公式誘導で確認してください。

AI代行時代の人間チェックは次の3点です。

  1. 差分を読む：three-dot diffで持ち込み分だけ見ます。小さなプルリクだと確認が速いです
  2. 再現を確認する：READMEの手順で第三者が実行できるか見ます
  3. 秘密・容量を確認する：秘密情報の混入と、大容量の置き場を確認します

AIが書いた説明文は、そのままにせず目的・変更点・確認観点を足してからレビュー依頼すると手戻りが減ります。データ基盤の運用整理は、MCPとはの外部連携の考え方とも合わせて読むと、自動化と手動確認の分担を決めやすいです。

よくある質問

Q1. GitHubとGitの違いは？

Gitは変更を追跡するバージョン管理システム（VCS）、GitHubはGitプロジェクトをクラウドでホストし、計画・コラボレーションツールを追加したものと説明されています。Gitが記録の仕組み、GitHubが置き場＋進め方と覚えると整理しやすいです。

Q2. 無料でどこまで使えますか？

2026年10月3日時点の公式表記では、GitHub Freeは$0で、publicはフル機能・無制限コラボレーター、privateは限定機能で無制限とされています。Actions分数やPages可否、容量は変動するため、詳細は公式料金表で確認してください。

Q3. PublicとPrivateはどちらにすべき？

Publicはインターネット上の全員がアクセス可、Privateは自分・明示共有者・Orgでは一部メンバーのみです。学習・秘密情報ありはPrivate推奨です。公開してよい成果物だけPublicにすると安全です。

Q4. add・commit・pushの違いは？

addはステージング（記録対象に載せる）、commitは履歴への保存（スナップショット）、pushはリモートへの反映です。add止まり・commit止まりが多いため、git statusで確認する癖を付けてください。

Q5. pushできない・403エラーになるのはなぜ？

PAT未使用・権限不足・キャッシュ済み資格・Org制限・既定ブランチ不存在を順に確認します。無トークン・権限不足は404／403、無効資格は401、classicがOrgで無効化されていると403と説明されています（REST API文書の説明。目安として捉えてください）。個別エラーメッセージの原文は未確認のため、メッセージ全文で公式Troubleshootingを確認してください。

Q6. プルリクからマージまでの流れは？

ブランチ作成→変更・コミット→プルリクエストオープン（base／compare選択）→レビュー→Merge／Squash／Rebaseでマージ→ブランチ削除（任意）の順です。同ブランチへの追加コミットは自動反映されます。CLIではgh pr create、gh pr mergeが使えます。

Q7. SSHとHTTPSはどちらでcloneすべき？

ファイアウォール下ではHTTPS＋PAT／GCM、手軽に鍵管理するならSSH＋ed25519が目安です。認証方式はclone時のリモートURLで決まります。PATはHTTPS専用のため、SSHリモートには切替が必要です。社内網の制限確認から始めてください。

Q8. Desktopを使えばコマンドなしで使えますか？

使えます。GitHub Desktopは無料・オープンソースでWin／Mac対応です。clone・branch・commit・push・PR checkoutをGUIで実施できます。典型フローはDesktopでclone＋branch→VS Code等で編集→Desktopでcommit＋pushです。

まとめ

本記事のまとめ

GitHubは、Gitの記録の仕組みにクラウドの置き場と協業機能を加えたものです。最小完走は「リポジトリ作成→clone→編集→status確認→add→commit→push」、チーム開発は「ブランチ→プルリク→マージ」の型で回します。認証はHTTPSならPAT＋保持、SSHならed25519＋登録、公開範囲はPrivate起点で進めると安全です。

まずは小さな練習リポジトリで5コマンド反復から試してみてください。READMEの1行修正で1周できると、ブランチやプルリクも同じ型で理解しやすいです。

次に着手する場合は、Privateの練習リポジトリ作成→clone→status確認→add→commit→pushの順で進めてみてください。慣れたらswitch -cでブランチを切り、プルリクを1件マージしてみてください。

AI実装スキルを磨きたい人へ

これからのAI時代に 「市場価値の高い人材」 とは、「モデルを使える人」ではなく 「業務に組み込んで価値を出せる人」 です。AI実装＋エンジニアリング＋業務理解の三点セットを磨くことが、5年後・10年後のキャリアに直結します。

※以下、PRを含みます

関連記事

参考文献

データ基盤・ツール
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

管理人のアバター 管理人 データエンジニア / ETL設計

基幹システム×データエンジニア｜DataEngineerLabs運営
大手食品系の基幹システム開発を経験。人事・給与・販売管理のデータ連携、ETL設計、SQLパフォーマンス、バッチ保守が専門。
データを"使える状態にする"難しさを発信中

関連記事

コメント

コメントする

目次