GitHub実践③ pushとpullで変更を共有しよう

VS Codeで保存したのにGitHubが変わらない。GitHubは変わったのに公開サイトが変わらない。初めてだと、どこまで届いているのか分からなくなりますよね。

今回は、手元のGit履歴をGitHubへ送るpushと、新しい変更を受け取るpullを整理します。前提は、最初のコミットがある練習用リポジトリです。大切な制作物ではなく、練習用で確認してください。

ローカルとリモート

ローカルは自分のパソコン側、リモートは接続して使う別のリポジトリ側です。今回はGitHubをリモートにします。

エディターで保存
  ↓ add と commit
パソコン内の履歴
  ↓ push
GitHubの履歴
  ↓ 公開サービスのビルド・デプロイ
読者が見る公開サイト

ビルドは公開用のファイルを作ること、デプロイは公開先へ配置することです。詳しくはプログラミング基本用語へ。

GitHubへ送るだけで必ずWebサイトが更新されるわけではありません。公開サービスとの連携がある場合に、さらに後ろの工程が動きます。

GitHubを接続する

1. 空のリポジトリを用意する

GitHubで練習用リポジトリを作ります。最初は公開範囲を Private（非公開）にすると、不用意な公開を避けやすくなります。ただし非公開でも、秘密鍵やパスワードを入れてよいわけではありません。

今回は手元に履歴があるので、GitHub側ではREADME・ライセンス・gitignoreの自動追加を選ばず、空で作ります。両側に別々の初回コミットを作ると、後で履歴を合わせる手順が必要になるためです。

すでにGitHub側に内容があるプロジェクトなら、まず clone で手元へ複製する方が自然です。cloneは、リポジトリと履歴をコピーして作業環境を作る操作です。既存の履歴に力ずくで上書きしないようにしましょう。

2. URLを自分のものへ置き換える

GitHubのリポジトリ画面に表示されたHTTPSのURLを使います。次の YOUR-ACCOUNT と YOUR-REPOSITORY は説明用なので、そのまま実行しません。

git remote add origin https://github.com/YOUR-ACCOUNT/YOUR-REPOSITORY.git
git remote -v

origin は接続先に付けた短い名前です。特別なサーバー名ではなく、よく使われる慣習です。git remote -v で、取得用と送信用のURLを確認します。

すでに origin があるというエラーが出たら、まず現在のURLを確認します。削除して作り直す前に、その接続先がほかの作業で使われていないか確かめてください。

3. ログイン情報と著者情報を区別する

前の記事で設定した user.name と user.email は、コミットに残す著者情報です。GitHubへ接続するための認証ではありません。

HTTPSでGitHubへ送る際は、対応する資格情報管理ツールのブラウザーログイン、GitHub CLI、必要に応じたアクセストークンなどを使います。GitHubアカウントのパスワードを、そのままGitのHTTPS認証に使う方式ではありません。

トークンは外部へ貼らず、URLの中にも埋め込まないでください。迷ったらGitHub公式のHTTPS接続の説明を確認します。

pushで変更を送る

1. 送る前に3つを見る

git status
git branch
git remote -v

確認するのは「コミット漏れはないか」「送るブランチはどれか」「送信先は自分の練習用か」です。今回は main を使います。

2. 初回のpushを行う

git push -u origin main

このコマンドは、ローカルの main の履歴を origin へ送り、次からの追跡先も設定します。追跡先はupstreamと呼ばれ、以後の git push や git pull の対象を決める手がかりになります。

成功したらGitHubの画面を更新し、README.md の内容と最新コミットのメッセージを見ます。ターミナルに成功らしい文字が出た、だけで終わらず、行き先で確かめるところまで行いましょう。

3. 次の変更を送る

READMEを編集・保存した後の流れです。

git diff
git add README.md
git diff --staged
git commit -m "READMEの説明を調整"
git push

push が送るのは、基本的にコミット済みの履歴です。保存しただけの変更や、ステージしただけの内容は、それだけでは届きません。

「Everything up-to-date」と出るのにファイルが古い場合は、送れるコミットが増えていない可能性があります。git status と git log --oneline -3 で、保存→コミットまで進んだかを確認します。

pullで変更を受け取る

別の端末やGitHubの画面で編集した内容は、手元へ自動で入るとは限りません。

1. 受け取る前に作業を確認する

git status

手元の編集中データがあれば、内容を確認して必要なものをコミットするなど、混ざらない状態に整えます。「邪魔だから削除する」はしません。

2. 履歴をまっすぐ進められる場合だけ取り込む

git pull --ff-only

pull は、変更を取得してから現在のブランチへ統合する操作です。--ff-only は、履歴の先をそのまま進められる場合だけ反映し、手元と相手が別々に進んでいたら停止する指定です。

停止は故障ではありません。「自動で混ぜず、どうまとめるか確認する必要がある」という意味です。そこで急いで push --force しないようにしてください。

fetchとの違い

fetchは、相手の履歴情報を取得しますが、現在の作業ブランチへはまだ統合しません。

git fetch origin
git log --oneline --graph --all -12

先に何が増えたか見たいときに使えます。両側に別の変更がある場合は、マージと競合の解説を参考に内容を確認します。pull の統合方法は設定やオプションでも変わるため、「ただのファイルダウンロード」と覚えない方が安全です。

公開してはいけない情報

次のものは、リポジトリへ入れないようにします。

パスワード、秘密鍵、アクセストークン
外部サービスの秘密のAPIキー
本人の同意なく公開する個人情報
公開・再配布する権利のない素材や課題データ

APIキーは、サービスを使うプログラムなどを識別する文字列です。秘密として扱うキーが漏れると、第三者に利用されるおそれがあります。

.gitignore は、Gitへ追加しないファイルを指定する設定です。例えば次のように書きます。

.env
.env.*
!.env.example
node_modules/

.env は秘密の設定値を入れることがあるファイルです。.env.example を残すなら、中身は名前とダミー値だけにします。

ただし、すでに追跡しているファイルは、gitignoreに書いても履歴から消えません。 漏れたキーは最初に無効化・再発行し、サービス側の利用状況を確認します。ファイルを削除するだけで解決したとは判断しないでください。

公開サイトに反映されないとき

順番に、どこまで進んだかを確認します。

確認する場所	見ること
エディター	保存済みか
`git status`	コミットしていない変更がないか
GitHub	正しいブランチに新しいコミットがあるか
公開サービス	そのコミットのビルドが成功したか
ブラウザー	正しい公開URLを見ているか

公開サービスの失敗を、何度もpushして直そうとしても原因は変わりません。ビルドのエラーなら、その工程の記録を読みます。全部の段階が成功してから、ブラウザーのキャッシュなどを疑います。

練習：送信前の状態を確認する

現在のブランチ、未記録の変更、送信先を調べる3コマンドを書いてください。

続いて「保存したがコミットしていないREADMEを、git push だけで送れるか」も考えてください。

模範解答

git branch
git status
git remote -v

保存しただけのREADMEは、push だけでは送れません。

解説

branch は履歴の現在地、status は作業ファイルと記録の状態、remote -v は接続先です。変更を確認して add と commit を済ませ、その後に push します。

「送る」と「記録する」を分けて覚えると、GitHubや公開サイトが変わらない場面でも、止まっている段階を見つけられます。