GitHubへコードを保存する：公開前の確認から初回pushまで

僕が個人開発のコードを初めてGitHubの非公開リポジトリへ保存したとき、気をつけたのは「何を送るか」を先に決めることでした。.gitignoreを用意し、git statusで対象を見てから保存する。この順番を習慣にすると、AIと一緒に変更したコードも追いやすくなります。

GitHubへアップロードする前に、公開範囲と除外するファイルを決めましょう。ここでは空のリポジトリへ、ローカルの小さなプロジェクトを初めてpushする流れを扱います。既存の履歴があるリポジトリへの強制上書きは扱いません。

最初は非公開でもよい

GitHubで新しいリポジトリを作成します。まだ公開できるか判断できないコードはPrivateにします。この手順ではREADME等を自動追加せず、空のリポジトリを作ります。既存のリポジトリにREADMEがある場合は、先にcloneする流れを選んでください。

.gitignoreを先に作る

プロジェクトのルートで、秘密や再生成できるファイルを除外します。利用する言語やツールに合わせて追加してください。

node_modules/
.next/
.env
.env.*
!.env.example
*.log

.env.exampleにも実際のキーは入れません。すでに追跡した秘密は.gitignoreを追加しても履歴から消えません。公開した認証情報は失効・再発行が必要になる場合があります。

Gitの準備

Gitをインストールし、ターミナルで確認します。初めてならコミットの名前・メールも設定します。以下の名前とメールは自分の値へ置換します。GitHubの非公開メールを使うこともできます。

git --version
git config --global user.name "あなたの名前"
git config --global user.email "あなたのコミット用メール"

追加するものを確認してからコミット

git init -b main
git status --short
git add .
git diff --cached --stat
git diff --cached
git commit -m "Create initial project"

git add .の前後で、キー、個人情報、生成物が含まれないか見ます。秘密があればコミットする前に取り除いてください。古いGitでinit -bが使えない場合は、初回コミット後にgit branch -M mainで名前をそろえます。

認証してpush

GitHubのHTTPS認証には、GitHub CLIやGit Credential Managerなどを使います。PATを使う場合は、認証を求められた画面へ入力します。手順をメモするときはトークンの値を除き、認証方法だけを残しておきましょう。

git remote add origin https://github.com/YOUR_NAME/YOUR_REPOSITORY.git
git push -u origin main

YOUR_NAMEとYOUR_REPOSITORYは自分のリポジトリへ置換します。originがすでにある場合はgit remote -vで確認し、別のリポジトリへ誤送信しないようにします。

保存できたか、GitHubの画面と手元の状態を比べる

pushが終わったらGitHubの対象リポジトリを開き、選んでいるブランチがmainで、最新コミットとファイルが表示されることを確認します。手元では次を実行できます。

git status --short
git log -1 --oneline
git branch -vv

git status --shortに何も出なければ、追跡対象の変更と未追跡ファイルはありません。ただし、GitHubへ送れた証拠はこの空表示だけではありません。pushの結果とGitHub側の最新コミットも照合します。branch -vvでは追跡先やahead/behindの表示を確認できます。

2回目からは、initではなく変更を記録する

たとえばindex.htmlだけを書き換えたなら、同じ作業フォルダで次を実行します。まず差分を読み、意図したファイルだけを追加します。

git diff -- index.html
git add index.html
git diff --cached -- index.html
git commit -m "Update page heading"
git push

初回のpush -uで追跡先を設定した同じブランチなら、以後はgit pushで送れます。初期化やoriginの追加を毎回やり直す必要はありません。別の人の更新で拒否された場合は、下のエラー欄を確認し、強制送信で上書きしないでください。

エラーを切り分ける

• Author identity unknown：コミット用の名前・メールを確認。
• Authentication failed：正式な認証方法と対象リポジトリへの権限を確認。
• Repository not found：git remote -vで所有者名とリポジトリ名を確認。Privateの場合は、そのリポジトリを読めるアカウントで認証しているかも確認。
• src refspec main does not match：コミットがあるか、ブランチ名が一致するか確認。
• rejected：リモートに先の履歴がないか確認。理由を見ずにforce pushしない。

保存ができたらVercelへの公開手順へ進めます。保存したコードを、次はブラウザから使える形へ公開します。

WordPressの記事原稿や編集記録も、非公開GitHubへ保存できます。CodexでWordPressの執筆・投稿・更新を管理する方法では、GitHubを保存先にし、WordPressへの反映と分けて運用する手順を説明しています。

保存した後にAIの修正だけを戻したくなったら、自分の編集を残しながらGitで変更を取り消す練習へ進めます。同じファイルに自分とAIの変更が混ざった場合や、すでにコミット・pushした場合を分け、小さな練習用ファイルで確認できます。

まず「いま開いている場所」を確かめる

Gitを始めるときに、コマンドの意味と同じくらい大事なのが実行場所です。VS Codeでプロジェクトのフォルダを開き、そのウィンドウからターミナルを起動すると、作業場所をそろえやすくなります。たとえば自己紹介ページなら、index.htmlとstyle.cssが入っているフォルダを開きます。デスクトップそのものをプロジェクトにしないよう、まずファイル一覧を見てください。

macOSやLinuxのターミナルではpwdとls、WindowsのPowerShellではGet-LocationとGet-ChildItemで現在地と中身が分かります。学校の資料や写真など、今回のコードと関係のないファイルが並んでいたら、そのままgit initへ進まず、目的のフォルダへ移動します。以下は、実行場所を取り違えた場合の練習例です。

pwd
ls
git rev-parse --show-toplevel

最後のコマンドは、すでにGitで管理している場合に、その一番上のフォルダを表示します。まだ初期化していなければ「not a git repository」と出ます。ここでデスクトップやホームフォルダが表示される場合は、親のフォルダですでに管理が始まっている可能性があります。別の階層へ新しい.gitを作る前に、管理範囲を見直しましょう。

間違った場所でinitした直後でも、ファイル本体が勝手にGitHubへ送られることはありません。git status --shortで対象を見て、コミットやpushをいったん止めます。自分で作った直後の.gitか、既存の大事な履歴を含む.gitかで対応が変わるため、正体を確かめないまま削除コマンドをコピーしないでください。練習なら、新しい専用フォルダへ必要なコードだけをコピーし、そこで始める方法もあります。

addとcommitで、何が保存されるのか

作業フォルダ、ステージ、コミット、GitHubを、四つの置き場所として考えると整理しやすいです。エディタで直した直後の内容は作業フォルダにあり、git addで次のコミットへ入れる内容を選びます。git commitで手元の履歴として記録し、git pushでその履歴をGitHubへ送ります。

ここで覚えておきたいのは、addした後にもファイルを編集できることです。addした時点の内容と、その後の編集が別々に残るので、「さっきaddしたから最新版が全部コミットされる」と思わず、git diff --stagedを読んでみてください。Gitはファイル名だけでなく、選んだ時点の変更内容を次の記録へ載せています。

git status --short
git diff
git add index.html style.css .gitignore
git diff --staged
git commit -m "Add profile page"

git diffはまだステージへ入れていない変更、git diff --stagedは次のコミットに入る変更を表示します。赤と緑の行を読んで、見出しの修正だけを頼んだのに設定ファイルまで変わっていないかを見ます。このブログの原稿管理でも、送る前に差分を読むことが、意図しない更新を防ぐ手掛かりになっています。

.envを後から.gitignoreに書いても、消えない理由

.gitignoreは、まだ追跡していないファイルを除外するための設定です。すでにgit addした.envはGitの管理対象なので、あとから.envという行を書いても、自動では外れません。ファイルの中身を消すのではなく、追跡対象から外す操作が必要です。

git ls-files -- .env
git check-ignore --no-index -v .env
git rm --cached -- .env
git diff --staged

git ls-filesに.envが出れば追跡されています。git rm --cachedはステージ側の管理から外す操作で、作業フォルダの.envを残せます。差分に「削除」と表示されても、ここではGitの次の記録から外れるという意味です。先に.gitignoreへ.envを書き、ほかの設定値まで消していないかを読んでからコミットします。未追跡の.envに対して実行すると、対象が見つからないという表示になります。

過去のコミットに入った値は、この操作だけで過去へさかのぼって消えません。もし本物の認証情報を送った場合は、まず提供元で失効・交換し、その後に履歴の扱いを検討します。次からは変数名だけを書いた.env.exampleを置くと、共同作業で必要な項目を伝えながら、値をリポジトリへ入れずに済みます。

HTTPSのパスワード欄へ、アカウントのパスワードは入れない

GitHubへHTTPSでpushするとき、GitHubアカウントのパスワードをそのまま使う認証は廃止されています。初めてならGitHub CLIでブラウザ認証を進めるか、Git Credential Managerを利用すると、トークンを手作業で管理する場面を減らせます。GitHub CLIを導入済みなら、gh auth loginを実行し、GitHub.com、HTTPS、ブラウザ認証の案内へ進めます。

gh auth login
gh auth status

ブラウザで表示されたアカウントが、送信先リポジトリを扱えるアカウントかを見てください。学校用と個人用を使い分けていると、ログインできていても権限が足りないことがあります。auth statusで利用中のアカウントを調べ、認証情報そのものは記事や質問へ貼りません。

Personal Access Tokenを使うなら、対象リポジトリと必要な権限を絞ります。非公開リポジトリへコードを送る用途に合う設定を選び、トークンは認証を求める入力欄や資格情報マネージャーで扱います。URLに埋め込むと、ターミナル履歴やgit remote -vへ値が残るので、通常のhttps://github.com/ユーザー名/リポジトリ名.gitという接続先を保ちます。

pushが通ったら、同じコミットが届いたかを見る

初回のgit push -u origin mainが成功したら、GitHubのCode画面でmainを選びます。最新コミットのメッセージとファイル一覧を、手元のgit log -1 --onelineと見比べてみてください。画面のブランチが違うだけで、送ったはずのファイルが見えないこともあります。

もしnon-fast-forwardと出たら、GitHub側に手元が持っていない履歴があります。README付きで作成したリポジトリへ、別に初期化したコードを送ろうとした場合もこの状況になります。初回の練習では空のリポジトリを用意するか、先にcloneしてからファイルを入れると、履歴をそろえやすいです。すでに共同作業をしているなら、相手のコミットを取り込む方法を決めてから進めます。

保存が一巡できたら、次は小さな変更を一つだけ加えて、diff、add、commit、pushをもう一度通してみてください。毎回同じ順番で内容を読めるようになると、AIへ修正を頼んだときも、変更を受け取る側の判断がしやすくなります。

参考にした公式資料

• GitHub：ローカルコードを追加
• GitHub：認証