ローカルからGitHubへ！git pushでファイルをアップロードする基本手順

前回の記事で、GitHub上に初めてのリポジトリ（保管場所）を作成し、最初のファイルをアップロード（プッシュ）することに成功しました。おめでとうございます！

今回は、その次のステップとして、日常的な開発作業で最もよく使う流れを学びます。具体的には、自分のPC（ローカル）で既存のファイルを編集したり、新しいファイルを追加したりした変更を、どうやってGitHubに反映させるか、という手順です。この「add → commit → push」という一連のサイクルは、Gitを使った開発の基本中の基本なので、ぜひマスターしていきましょう！

Gitの基本ワークフロー：3つの「場所」を覚えよう

Gitの操作を理解する上で、まず知っておきたいのが「3つの場所」という考え方です。Gitは、ファイルの変更を記録するまでに、一時的な保管場所を挟みます。これにより、どの変更を記録に残すかを柔軟に選べるようになっています。

• 作業ディレクトリ (Working Directory): あなたが実際にファイルを開いて編集している、PC上のフォルダそのものです。
• ステージングエリア (Staging Area): コミット（セーブ）したい変更内容を、一時的に置いておく場所です。「次のセーブポイントに含める変更リスト」のようなイメージです。
• ローカルリポジトリ (Local Repository): ステージングエリアにある変更内容を、正式なセーブポイント（コミット）として記録・保管する場所です。あなたのPC内の`.git`フォルダに、これまでの全履歴が保存されています。

この3つの場所の間で、ファイルを移動させていくのがGitの基本的な流れになります。

1. 作業ディレクトリでファイルを編集・作成する。
2. git addコマンドで、コミットしたい変更をステージングエリアに上げる。
3. git commitコマンドで、ステージングエリアにある変更をローカルリポジトリに記録する。
4. git pushコマンドで、ローカルリポジトリの記録をGitHub（リモートリポジトリ）に送信する。

では、実際にこの流れを体験してみましょう！

実践！ファイルを変更・追加してGitHubに反映させる

前回の記事で作成した`my-first-repo`フォルダを使って作業を進めます。まだ開いていない方は、ターミナル（またはGit Bash）でそのフォルダに移動してください。

cd my-first-repo

ステップ1: 既存ファイルを編集し、変更を確認する (git status)

まず、前回作成した`index.html`をお好みのエディタで開き、中身を書き換えてみましょう。

例： `Hello, GitHub!` を `Hello, World!` に変更して保存します。

ファイルが変更されたことをGitが認識しているか、`git status`コマンドで確認します。これは「今のプロジェクトの状態はどうなってる？」とGitに尋ねるコマンドです。

git status

`modified: index.html`のように、`index.html`が変更されたことが報告されるはずです。

ステップ2: 新しいファイルを追加する

次に、新しいCSSファイルを作成してみましょう。以下のコマンドで、簡単なCSSファイルを作成します。

echo "h1 { color: steelblue; }" > style.css

この状態で再度`git status`を実行すると、今度は「追跡されていないファイル (Untracked files)」として`style.css`が表示されます。これは、Gitがまだこのファイルの存在を知らない、という意味です。

git status

ステップ3: 変更をステージングする (git add)

「変更した`index.html`」と「新しく作った`style.css`」の両方を、次のセーブポイントに含めるためにステージングエリアに上げましょう。`git add`コマンドは、変更されたファイルにも、新しいファイルにも使えます。

一般的には、以下のコマンドで作業ディレクトリ内のすべての変更（新規追加・修正）を一度にステージングします。

git add .

この後、もう一度`git status`を実行すると、すべての変更が「Changes to be committed（コミットされるべき変更）」として緑色で表示され、ステージングが完了したことがわかります。

ステップ4: 変更をコミットする (git commit)

ステージングエリアに上げた変更内容を、一つのセーブポイントとしてローカルリポジトリに記録します。今回何をしたのかが分かるように、具体的なメッセージを付けましょう。

git commit -m "index.htmlのテキストを更新し、style.cssを追加"

ステップ5: GitHubにプッシュする (git push)

最後に、ローカルリポジトリに作成した新しいコミットを、GitHub上のリモートリポジトリに送信（プッシュ）します。これで、あなたの変更がチームメンバーにも共有され、安全なバックアップとなります。

2回目以降のプッシュでは、最初の`-u`オプションは不要です。

git push origin main

確認と注意点

プッシュが完了したら、GitHubのリポジトリページをブラウザで再読み込みしてみてください。`style.css`が追加され、`index.html`の最終更新日時やコミットメッセージが変わっているはずです。これで、変更内容が正しくGitHubに反映されたことが確認できました。

• `git status`を癖にしよう: 何か作業をする前や、コミット・プッシュする前には、必ず`git status`で現在の状態を確認する癖をつけると、意図しないファイルの追加や変更を防げます。
• コミットは意味のある単位で: 「ヘッダーのデザインを修正」「フッターのリンクを追加」など、関連する変更を一つのコミットにまとめるように心がけましょう。履歴がきれいになり、後から変更を追いやすくなります。

push前に見るべき3つの確認

git pushは便利ですが、間違ったファイルを含めたまま実行すると、その変更もGitHubへ送られます。特にAIにコード修正を頼んだあとや、Webサイトの公開前には、次の3つを確認してからpushします。

# 変更されたファイル一覧を見る
git status

# まだステージしていない差分を見る
git diff

# コミットに入る予定のファイルを見る
git diff --cached --name-only

AIに修正してもらったコードをpushする場合は、差分確認と公開前チェックをセットにします。公開前の考え方はAIコード修正と公開前チェックの入口から確認できます。

GitHubへpushしても本番サイトは自動で変わらない

初心者が混同しやすい点ですが、git pushは「GitHubへ履歴を送る操作」です。レンタルサーバーやFTPで公開しているサイトでは、pushしただけで本番サイトのHTMLやPHPが自動更新されるとは限りません。

ロリポップなどへFTPで公開している場合は、push後に必要なファイルをサーバーへアップロードし、公開URLで確認するところまでが一連の公開作業です。公開後に反映されない場合は、Web公開トラブル解決の入口でアップロード先、キャッシュ、URLを順番に確認します。

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

pushでエラーが出ても、すぐにやり直し続けるより、エラーの種類を分けて見るほうが早く解決できます。

ブランチ名や作業の分け方で迷う場合は、Gitブランチ運用の基本を確認すると、mainへ直接pushしてよい場面と分けたほうがよい場面を判断しやすくなります。

# いま変更中のファイルを見る
git status

# まだcommitしていない差分を見る
git diff

# commit済みの直近履歴を見る
git log --oneline -5

# GitHub側の最新情報を取得する
git fetch

# いまのブランチ名を見る
git branch --show-current

# push先URLを見る
git remote -v

git pushの問題を切り分けたいです。

やりたいこと:
実行したコマンド:
表示されたエラー:

確認済み:
- git status:
- git branch --show-current:
- git remote -v の種類:
- git log --oneline -5:
- 初回push済みか:
- GitHubで見ているブランチ:

相談したいこと:
- push前にcommitできているか
- push先ブランチが合っているか
- rejected の時にpull/fetchが必要か
- 戻すならrestore/revertのどちらが安全か

伏せる情報:
- GitHubトークン
- パスワード
- 秘密鍵
- 非公開リポジトリURLの必要以上の情報
- .envやDB設定ファイルの中身

git status
git diff --cached --name-only