GitHubとは？初心者向けにリポジトリ作成からコード公開まで実例で解説

「GitHubという名前は聞くけれど、Gitと何が違うのか分からない」

「自分のPCにあるファイルをGitHubへ公開するには、何をすればいいの？」

Gitを使い始めると、次に出てくるのがGitHubです。

GitHubは、Gitで管理しているコードやファイルをオンライン上で保存・共有できるサービスです。

ただし、初心者がいきなりGitHubを使おうとすると、

• GitとGitHubの違いが分からない
• Repositoryという言葉で止まる
• PublicとPrivateのどちらを選べばいいか迷う
• git push で認証エラーになる
• origin や main の意味が分からない

といったところでつまずきやすくなります。

この記事では、GitHub初心者向けに、

• GitとGitHubの違い
• リポジトリとは何か
• PublicとPrivateの選び方
• GitHubで新しいリポジトリを作る方法
• PC上のGitリポジトリをGitHubへ送る方法
• pushできないときの確認順
• GitHubへ載せてはいけない情報

まで、実際の操作の流れに沿って解説します。

GitHubとは

GitHubは、Gitで管理しているリポジトリをオンライン上で保存・共有できるサービスです。

GitとGitHubは同じものではありません。

簡単に整理すると、

Git
＝ ファイルの変更履歴を管理する仕組み

GitHub
＝ Gitで管理しているものをオンライン上で保存・共有できるサービス

です。

Gitだけでも、自分のPC内で変更履歴を管理できます。

GitHubを利用すると、そこからさらに、

別のPCからリポジトリを見る

他の人とコードを共有する

Pull Requestで変更内容を確認する

Issueで作業や問題を管理する

GitHub Actionsでテストなどを自動化する

といったことができるようになります。

つまりGitHubは、単なる「コード置き場」ではありません。

Gitによる変更管理を、共有・レビュー・自動化などへ広げるための場所

と考えると分かりやすくなります。

リポジトリとは

GitHubを使うと頻繁に出てくるのが「Repository（リポジトリ）」という言葉です。

初心者のうちは、

Gitで管理している1つのプロジェクト

くらいに考えて構いません。

たとえば、

社内ツールA
WebサイトB
Python練習用プログラム

をそれぞれGitで管理しているなら、それぞれ別のリポジトリとして管理できます。

GitHub上でも、通常はプロジェクトごとにリポジトリを作ります。

PublicとPrivateの違い

GitHubでリポジトリを作るときは、公開範囲を選びます。

主に、

Public
Private

があります。

Public

Publicリポジトリは、基本的にインターネット上から内容を見ることができます。

オープンソースのコードや、公開して問題のない学習用プロジェクトなどで利用されます。

Private

Privateリポジトリは、アクセスを許可された人だけが内容を確認できます。

会社の業務に関係するコードや、外部へ公開する必要のないプロジェクトであれば、Privateを選ぶケースが多くなります。

初心者だからPublicを選ぶ必要はありません。

判断に迷ったら、

「このファイルをインターネット上の誰に見られても問題ないか」

で考えてください。

少しでも判断できない情報が含まれているなら、安易にPublicへしない方が安全です。

GitHubへ載せてはいけない情報

PublicかPrivateかに関係なく、GitHubへ保存する内容には注意が必要です。

特に、

パスワード
APIキー
アクセストークン
秘密鍵
データベース接続情報
社内システムの認証情報
個人情報
機密情報

などを、そのままリポジトリへ保存してはいけません。

たとえば、

.env

などのファイルに秘密情報を保存しているプロジェクトでは、.gitignore などを利用してGitの管理対象から外す運用がよく使われます。

大切なのは、

GitHubへpushする前に、何がcommitされているのか確認すること

です。

今回行うこと

今回は、自分のPCですでにGit管理している練習用プロジェクトをGitHubへ送ります。

全体の流れは次のとおりです。

PC上でGitリポジトリを用意
↓
GitHubで空のリポジトリを作る
↓
ローカルとGitHubを接続
↓
git push
↓
GitHub上でファイルを確認

今回はGit自体の基本操作はできている前提で進めます。

まだGitに慣れていない場合は、まず git status、git add、git commit の流れを理解してから進めると分かりやすくなります。

PC側の状態を確認する

まず、GitHubへ送りたいプロジェクトのフォルダで、

git status

を実行します。

Gitで管理されているリポジトリなら、現在の状態が表示されます。

続けて、

git log --oneline

を実行すると、commit履歴を簡潔に確認できます。

GitHubへ送る前に、

変更がcommitされているか

不要なファイルが含まれていないか

秘密情報が入っていないか

を確認しておきましょう。

特に会社のPCや業務データを扱う場合は、pushする直前の確認が重要です。

GitHubで新しいリポジトリを作る

GitHubへログインしたら、新しいリポジトリを作成します。

GitHub画面から、

New repository

を選びます。

入力する主な項目は、

Repository name
Description
Public / Private

です。

Repository name

リポジトリ名です。

たとえば、

python-practice

のように、何のプロジェクトなのか分かる名前を付けます。

Description

リポジトリの説明です。

必須ではありませんが、

Python学習用のサンプルプログラム

のように簡単な説明を書いておくと、後から見たときに分かりやすくなります。

Public / Private

公開してよいプロジェクトならPublic、公開する必要がないものならPrivateを選びます。

業務用ファイルの場合は、自社のルールも確認してください。

既存のローカルプロジェクトを送るなら、GitHub側を空で作る

今回のように、

PC側ですでにGit管理しているプロジェクトをGitHubへ送る

場合は、GitHub側で新しいリポジトリを作成するときに注意があります。

READMEや.gitignore、LicenseなどをGitHub側で先に作成すると、ローカル側とは別の履歴が作られます。

その結果、最初のpushで余計な競合が発生することがあります。

そのため、今回はGitHub側のリポジトリを空の状態で作ります。

PC側
すでにGit管理済み

↓

GitHub側
空のリポジトリを作る

↓

PC側の内容をpush

という流れです。

GitHubのリポジトリURLを確認する

リポジトリを作成すると、GitHub上に接続先URLが表示されます。

たとえばHTTPSなら、

https://github.com/ユーザー名/リポジトリ名.git

という形式です。

このURLを使って、自分のPC側のGitリポジトリとGitHubを接続します。

git remote add origin でGitHubを登録する

PC側のリポジトリで次のコマンドを実行します。

git remote add origin https://github.com/ユーザー名/リポジトリ名.git

ここで、

origin

という名前が出てきます。

origin はGitHubそのものの名前ではありません。

Gitではリモートリポジトリへ名前を付けて管理でき、その接続先に慣習的によく使われる名前が origin です。

初心者のうちは、

origin
＝ 今回登録したGitHub側の接続先

くらいに理解しておけば十分です。

接続先を確認する

登録後は、

git remote -v

を実行します。

GitHubのURLが表示されれば、リモートの登録を確認できます。

たとえば、

origin  https://github.com/ユーザー名/リポジトリ名.git

のように表示されます。

pushで問題が起きたときも、

そもそもどこへ送ろうとしているのか

を確認するために git remote -v が役立ちます。

ブランチ名を確認する

次に現在のブランチを確認します。

git branch --show-current

今回は、

main

をGitHubへ送るものとします。

もしブランチ名をmainへ変更する必要がある場合は、

git branch -M main

とできます。

ただし、既存のチームリポジトリなどでは勝手にブランチ名を変更しないでください。

今回は新しい練習用リポジトリを作る例です。

GitHubへpushする

準備ができたら、

git push -u origin main

を実行します。

ここでは、

origin

という接続先へ、

main

ブランチを送っています。

-u を指定すると、ローカルのmainとリモート側のmainの対応関係が設定されます。

その後は状況に応じて、

git push

だけで送れるようになります。

GitHubでファイルを確認する

pushが成功したら、ブラウザでGitHubのリポジトリを開きます。

自分のPCにあったファイルがGitHub上にも表示されていれば成功です。

ここで、

想定していたファイルだけがあるか

不要なファイルが含まれていないか

秘密情報が表示されていないか

も確認しましょう。

単に「push成功」と表示されたから終わりではなく、

GitHub側でも結果を確認する

ところまで行うのがおすすめです。

GitHubの認証で注意すること

GitHubへHTTPSでpushすると、認証が必要になります。

ここで注意したいのが、

GitHubのアカウントパスワードを、そのままGit操作のパスワードとして使う方式ではない

という点です。

現在は、たとえば、

GitHub CLI
Git Credential Manager
Personal Access Token
SSH

などを使って認証します。

WindowsでGitを利用している場合は、Git Credential Managerによってブラウザ認証画面が表示されることもあります。

認証画面が表示されたら、内容を確認してGitHubへログインします。

「パスワードを入力しているのにpushできない」ときは、Gitのコマンドよりも先に、

GitHubへの認証方法が正しいか

を確認してください。

remote origin already exists と表示されたとき

次のコマンドを実行したとき、

git remote add origin ...

すでに origin が登録されていると、

remote origin already exists

というエラーが出ることがあります。

この場合、すぐにoriginを削除するのではなく、

git remote -v

を実行します。

現在どのURLが登録されているか確認してください。

正しいGitHubリポジトリがすでに登録されているなら、新しく追加する必要はありません。

別のURLが登録されている場合は、

なぜその接続先が登録されているのか

を確認してから変更します。

Repository not found と表示されたとき

Repository not found が表示された場合は、次のような原因が考えられます。

GitHubのURLが間違っている

リポジトリ名が違う

ログインしているGitHubアカウントが違う

Privateリポジトリへの権限がない

認証が正常にできていない

まず、

git remote -v

で接続先を確認します。

そのURLをブラウザから開いて、自分がアクセスできるリポジトリなのか確認するのも有効です。

いきなりGitを再インストールする必要はありません。

Authentication failed が表示されたとき

認証エラーの場合は、

GitHubへログインしているアカウント

Gitが利用している認証情報

リポジトリへのアクセス権

HTTPSかSSHか

を確認します。

PCで複数のGitHubアカウントを使用している場合、別アカウントの認証情報が保存されていることもあります。

この場合も、コードやcommitを変更する前に、

誰としてGitHubへ接続しているのか

を確認します。

pushが拒否されたとき

GitHub側とローカル側で履歴が異なる場合などには、pushが拒否されることがあります。

ここで、

--force

を見つけたからといって、意味を確認せず実行するのは避けてください。

強制pushは、状況によってリモート側の履歴へ影響します。

まず、

git status
git branch --show-current
git remote -v
git log --oneline

などで現在の状態を確認します。

特に他の人と共有しているリポジトリでは、独断でforce pushしない方が安全です。

READMEは何のためにある？

GitHubのリポジトリを開いたときによく表示されるのが、

README.md

です。

READMEには、そのプロジェクトについて、

何をするものなのか

どう使うのか

必要な環境

実行方法

注意事項

などを書きます。

たとえば、

# File List Tool

指定したフォルダのファイル一覧をCSVへ出力するPythonプログラムです。

## 実行方法

python file_list.py

のような簡単な内容でも構いません。

数か月後に自分で見たときにも、

何のために作ったリポジトリなのか分かる状態

にしておくと管理しやすくなります。

.gitignore は何のためにある？

Gitで管理する必要がないファイルを除外するために使うのが、

.gitignore

です。

Pythonなら、たとえば、

__pycache__/
*.pyc
.env

などをGitの管理対象から除外することがあります。

ただし、

.gitignore に書けば、すでにcommitした秘密情報まで消える

わけではありません。

重要な情報をGitへ登録してしまった場合は、単に.gitignoreへ追加して終わりではなく、漏えいした可能性を考えて認証情報の無効化や再発行なども検討する必要があります。

そのため、最初から秘密情報をcommitしないことが重要です。

GitHubへ公開する前のチェックリスト

特に初心者は、pushの直前に次の内容を確認すると安全です。

□ git statusを確認した

□ 不要なファイルをcommitしていない

□ パスワードを含んでいない

□ APIキーを含んでいない

□ 個人情報を含んでいない

□ 社内情報を含んでいない

□ Public / Privateを確認した

□ git remote -vで送信先を確認した

□ 現在のブランチを確認した

会社のデータを扱う場合は、自社のセキュリティルールやGitHub利用ルールも確認してください。

ChatGPTなどのAIを使うときの注意点

GitHubのエラーを調べるときに、ChatGPTなどのAIを使うこともできます。

たとえば、

GitHubへgit pushしようとしたところ、
次のエラーが出ました。

実行したコマンド：
git push -u origin main

エラー：
ここにエラー全文

git status：
ここに結果

git remote -v：
ここに結果

原因と、安全に確認する順番を説明してください。
強制pushはしないでください。

のように相談すると、状況を整理しやすくなります。

ただし、エラー全文を貼る前に、

アクセストークン
ユーザー情報
社内URL
秘密情報

などが含まれていないか確認してください。

また、AIから、

git push --force
git reset --hard

などの影響が大きいコマンドを提案された場合は、意味を確認せず実行しないことが重要です。

AIは原因を考える補助として利用し、

最終的にどの操作を実行するのかは、現在のGitの状態を確認して判断する

ようにしましょう。

GitHubへ公開できたら次はブランチとPull Request

ここまでできれば、

PCでファイルを変更
↓
Gitでcommit
↓
GitHubへpush

という基本的な流れは完成です。

次のステップは、

mainを直接変更する

のではなく、

作業用ブランチを作る
↓
変更する
↓
pushする
↓
Pull Requestを作る
↓
確認してからmainへ反映する

という運用です。

チーム開発だけでなく、1人で開発するときにも変更内容を確認しやすくなります。

まとめ｜GitHubへ送る前の確認が重要

GitHubは、Gitで管理しているコードやファイルをオンライン上で保存・共有できるサービスです。

初心者がまず覚えたい流れは、

ローカルでGit管理する
↓
GitHubでリポジトリを作る
↓
git remoteで接続する
↓
git pushする
↓
GitHub上で結果を確認する

です。

コマンドだけを見ると難しく感じるかもしれません。

しかし重要なのは、

何を送るのか

どこへ送るのか

どのブランチを送るのか

誰に公開されるのか

を把握することです。

特に、

git status
git remote -v
git branch --show-current

を確認する習慣を付けると、誤ったファイルや別のリポジトリへ操作するリスクを減らせます。

そしてGitHubへ送る前には、秘密情報や社内情報が含まれていないか必ず確認してください。

まずは公開して問題のない練習用プロジェクトを用意し、GitHubへ1回pushするところから試してみましょう。