GitHubの使い方入門｜リポジトリ作成からpushまでの流れを解説

GitHubを使う最初の山場は、Webでリポジトリを作って、手元のファイルをpushできる状態にすることです。ここを越えると、バックアップ、共同開発、ソースコード共有が一気にやりやすくなります。

この記事では、GitHubアカウントを持っている初心者向けに、リポジトリ作成からpushまでを順番に整理します。実務でよくある「既存フォルダをあとからGitHubに載せたい」場面を前提に、コマンドの意味とつまずきやすい点までまとめます。

• できること: GitHubで新しいリポジトリを作り、ローカルのファイルを登録して公開または非公開で管理できる
• 使う場面: ソースコードの保存、制作物のバックアップ、チーム共有、ポートフォリオ公開
• この記事の前提: GitHubアカウント作成済み、PCにGitインストール済み、ターミナルが使える状態

ここがポイント: GitHubは「保存場所」、Gitは「変更履歴を管理する仕組み」です。pushは、手元の履歴をGitHubへ送る操作を指します。

まず押さえたい全体の流れ

最初に全体像をつかむと、コマンドの意味が追いやすくなります。

1. GitHubで空のリポジトリを作る
2. PC上の作業フォルダをGit管理にする
3. ファイルをaddしてcommitする
4. GitHubのリポジトリをremoteとして登録する
5. pushしてGitHubへ反映する

この5段階です。初心者が混乱しやすいのは、GitHubの操作とGitの操作が混ざることですが、実際には「Webで箱を作る」「ローカルで中身を入れる」と考えると整理しやすくなります。

対象環境と事前準備

この手順は、次のような前提で進めます。

• GitHub: ブラウザから利用
• Git: 2.x系
• OS: Windows / macOS / Linux のどれでも基本の流れは共通
• 作業対象: すでにPC上にあるフォルダ、またはこれから作る新規フォルダ

確認しておきたい点は次のとおりです。

• GitHubにログインできる
• ターミナルまたはコマンドプロンプトを開ける
• git --versionでGitのバージョンが表示される

たとえば、ターミナルで次を実行しておくと安心です。

git --version

表示例:

git version 2.44.0

バージョン番号は異なっていても、2.x系ならこの記事の基本操作はほぼ同じです。

GitHubでリポジトリを作成する

最初に、GitHub上に保存先を作ります。

作成手順

1. GitHubにログインする
2. 右上の+からNew repositoryを選ぶ
3. Repository nameに名前を入れる
4. PublicまたはPrivateを選ぶ
5. ひとまず空で作るなら、READMEや.gitignoreは必須ではない
6. Create repositoryを押す

名前の付け方

リポジトリ名は、あとでURLや作業時の識別にそのまま出ます。業務でも個人開発でも、次のように役割が分かる名前が扱いやすいです。

• sales-report-tool
• my-portfolio-site
• python-csv-cleanup

READMEをWeb側で先に作る方法もありますが、ローカルに既存フォルダがあるなら空リポジトリで始めるほうが衝突を避けやすいです。

ローカルフォルダをGit管理にする

次に、PC上のフォルダをGitで追跡できる状態にします。

新規フォルダの場合

mkdir sample-project
cd sample-project
git init

既存フォルダの場合

cd /path/to/your/project
git init

git initを実行すると、そのフォルダに.gitという管理用ディレクトリが作られます。これで、その場所がGitの管理対象になります。

表示例:

Initialized empty Git repository in /path/to/your/project/.git/

ファイルをaddしてcommitする

GitHubへ送る前に、まずローカルで変更を記録します。ここで使うのがaddとcommitです。

役割の違い

• git add: 次の記録対象にファイルを載せる
• git commit: その時点の内容を履歴として確定する

最小手順

git add .
git commit -m "first commit"

実務では、いきなりadd .を使う前に状態確認を入れると事故を減らせます。

git status
git add .
git status
git commit -m "first commit"

git statusで見えること

• まだ追跡されていないファイル
• add済みのファイル
• 変更はあるが未登録のファイル
• 今いるブランチ名

statusを見ずに進めると、不要ファイルまでpushしやすくなります。.env、認証情報、個人情報を含むファイルがないかはここで必ず確認してください。

GitHubのリポジトリをremote登録する

ローカルで履歴を作っただけでは、まだGitHubとはつながっていません。そこで、GitHubのURLをremoteとして登録します。

GitHubでリポジトリを作ると、HTTPSやSSHのURLが表示されます。まずは初心者でも分かりやすいHTTPSの例で進めます。

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

登録できたかは次で確認できます。

git remote -v

表示例:

origin  https://github.com/username/sample-project.git (fetch)
origin  https://github.com/username/sample-project.git (push)

originは慣例的によく使われる名前です。特別な意味というより、「このリポジトリの主な送信先」と考えれば十分です。

pushするまでの実行例

ここまでを通しで並べると、最小構成は次の形です。

cd /path/to/your/project
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
git push -u origin main

各コマンドの意味

• git branch -M main: 現在のブランチ名をmainにそろえる
• git push -u origin main: originにあるmainへ送る
• -u: 次回以降、git pushだけで送りやすくする設定

最近のGitHubでは既定ブランチとしてmainが使われることが多いため、最初にそろえておくと分かりやすくなります。

初回push後に起きること

初回のpushが通ると、GitHubのリポジトリ画面にファイル一覧が表示されます。これで、ローカルの内容がGitHub上に反映された状態です。

以後は、変更のたびに次の流れを繰り返します。

git add .
git commit -m "update files"
git push

入力例と結果のイメージ

たとえば、ローカルに次のようなファイルがあるとします。

sample-project/
  index.html
  style.css
  script.js

このフォルダでgit initからpushまで行うと、GitHub上でも同じ構成でファイルが見えるようになります。

どんなときに便利か

• Web制作の静的ファイルを保存したいとき
• PythonやNode.jsの学習用コードを残したいとき
• 複数人で同じプロジェクトを共有したいとき
• PC故障に備えてコードの退避先を持ちたいとき

単なるバックアップに見えても、変更履歴が残ることがGitHubの強みです。どこを直したか、いつ戻せるかが見えるので、実務での安心感が違います。

よくある失敗と対処法

ここは初心者がつまずきやすい部分です。エラー文をそのまま読むと分かりづらくても、原因はかなりパターン化しています。

remote origin already exists

すでにoriginが登録済みです。

確認:

git remote -v

URLを修正したい場合:

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

nothing to commit

変更がないか、add対象が存在しません。

確認ポイント:

• ファイルを本当に保存したか
• 正しいフォルダでコマンドを打っているか
• git statusで変更が見えているか

src refspec main does not match any

多くは、まだ一度もcommitしていないか、ブランチ名がmainではないケースです。

対処の順番:

1. git statusで状態確認
2. git commit -m "first commit"を実行
3. git branch -M mainでブランチ名を統一
4. もう一度git push -u origin main

認証で失敗する

HTTPSでpushする場合、環境によってはパスワードではなく、ブラウザ認証やトークン利用が必要です。GitHubはアカウント保護を重視しているため、古い手順のままでは通らないことがあります。

注意点:

• GitHubアカウントの通常パスワードをそのまま使えない場合がある
• 認証情報をスクリプトや平文ファイルに直接書かない
• 共用PCでは資格情報の保存方法に注意する

実務で使うなら入れておきたい設定

最初の1回だけ設定しておくと、commit時の情報が整います。

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

なぜ必要か

commitには作成者情報が付きます。チーム開発では、誰の変更か追えないとレビューや調査がしにくくなります。

あわせて考えたいファイル

不要なものまでGitHubへ送らないために、.gitignoreも重要です。

例:

node_modules/
.env
.DS_Store
__pycache__/

特に.envはAPIキーや接続情報を入れやすいので、最初から除外設定しておくほうが安全です。

GitHub DesktopやVS Codeとの違い

コマンド操作が不安な場合は、別の入口もあります。ただし、基本の流れを知っておくとツールが変わっても対応できます。

GitHub Desktopが向く人

• 画面で変更内容を見ながら進めたい
• コマンド入力にまだ慣れていない
• 個人開発や小規模作業から始めたい

VS Code連携が向く人

• エディタの中で変更確認からcommitまで済ませたい
• 普段からVS Code中心で作業している

CLIが向く場面

• サーバーや開発環境をまたいで同じ手順を使いたい
• エラー原因を自分で切り分けたい
• 実務でGit操作の意味をきちんと理解しておきたい

ツールは違っても、根本は同じです。add、commit、pushの意味が分かれば、どの操作画面でも迷いにくくなります。

最低限覚えておきたいコマンド一覧

作業前後によく使うものだけ、最後に絞っておきます。

• git init: Git管理を開始する
• git status: 現在の状態を確認する
• git add .: 変更を記録対象に載せる
• git commit -m "message": 履歴として保存する
• git remote add origin URL: GitHubを送信先に登録する
• git push -u origin main: 初回の送信
• git push: 2回目以降の送信

まとめ

GitHubの使い方を最短で押さえるなら、「リポジトリ作成」→「git init」→「add」→「commit」→「push」の流れを手元で一度通すのがいちばん確実です。

最初はコマンドが多く見えても、毎回使うのはほぼ同じです。次に確認すべきなのは、.gitignoreで除外すべきファイルがないか、そして認証まわりで止まったときにGitHub公式の案内に沿って設定できるかです。この2点を押さえるだけで、公開用でも業務用でもかなり安定して運用しやすくなります。

参照リンク

• GitHub Docs: Create a repo
• GitHub Docs: About remote repositories
• GitHub Docs: Adding locally hosted code to GitHub
• GitHub Docs: About authentication to GitHub
• Git Documentation: git init
• Git Documentation: git add
• Git Documentation: git commit
• Git Documentation: git push
• Git Documentation: git status
• Git Documentation: git remote
• Git Documentation: gitignore