GitHubの使い方｜初心者がブラウザーで変更・レビューを練習する手順

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

GitHubの使い方を覚える最初の一歩は、難しいコマンドを並べることではなく、小さなファイルを変更し、差分を確認して、元の流れへ取り込むことです。自分専用の練習場所で「作成→ブランチ→コミット→プルリクエスト→マージ」を一巡すると、共同作業で何を確認する道具なのかが見えてきます。最初はブラウザーだけでも、この流れを体験できます。

この記事では架空の旅行準備メモを題材に、READMEへ項目を追加する練習をします。実際の旅程、氏名、住所、予約番号は使いません。プログラムを実行する課題ではなく、文章の変更を通じて履歴とレビューを理解する課題です。Gitのコマンド操作やアプリの公開は、この流れが分かってから別に学べば構いません。

操作の根拠は2026年10月3日に確認したGitHub公式資料です。画面の配置や機能の利用条件は、アカウント、契約、組織の方針によって変わります。図版は説明用に生成したイメージで、GitHubの実画面ではありません。仕事のリポジトリでは、この記事の練習をそのまま行わず、所属先の運用ルールと権限に従ってください。

GitHubの役割を理解する｜ファイル・履歴・共同作業の関係

GitとGitHubは、仕組みとサービスとして分ける

Gitはファイルの変更履歴を管理する仕組みで、GitHubはGitのリポジトリを置き、変更の相談や確認、共同作業を行うためのサービスです。Gitを使うことと、GitHubへ公開することは同じではありません。手元のPCだけで履歴を管理する使い方もありますし、GitHub上に非公開のリポジトリを作る使い方もあります。

初心者が混乱しやすいのは、ローカルで保存したこと、Gitでコミットしたこと、GitHubへ送ったことを一つに考えてしまう点です。PC上の作業ではそれぞれ段階が違います。一方、今回のようにGitHubのブラウザー画面で編集しコミットする場合は、変更をGitHub上へ直接記録します。この練習に、PCからのpushを無理に追加する必要はありません。

GitHubにはコード以外の文章や設定ファイルも置けます。ただし、画像や動画など大きなデータの置き場所として無制限に使えるわけではありません。最初の練習を小さなテキストにするのは、差分が読みやすく、アップロード範囲を管理しやすいからです。「何でもまとめて置けばバックアップになる」と考えず、目的と公開範囲に合うファイルだけを扱いましょう。

リポジトリ・コミット・ブランチを一つの例で考える

今回のリポジトリは、旅行準備メモのファイルと変更履歴を置く入れ物です。コミットは「雨具の項目を追加した」など、一まとまりの変更を履歴へ記録する区切りです。ブランチは、基準となる流れとは分けて変更を進めるための作業の流れです。単に同じファイルを別名で何枚も作る方法より、どこで分かれ、何が変わったかを確かめやすくなります。

基準のブランチはmainという名前のことが多いですが、既存のリポジトリでは違う名前の場合もあります。この記事ではmainを例にします。名前が違っていても、基準となるブランチと作業用ブランチの関係を読み替えてください。mainという名前だから必ず本番サービスへ直結する、作業用だから誰にも見えない、という意味ではありません。

ブランチを分けると、確認前の変更をすぐ基準へ混ぜずに済みます。ただし、同じリポジトリのブランチは、通常そのリポジトリへのアクセス範囲の中にあります。秘密の下書きを隠すための仕組みではないので、公開リポジトリの作業ブランチへ個人情報を置かないでください。作業の分離と、情報を見られる範囲の管理は別に考えます。

※表は横にスクロールできます。

プルリクエストは変更を確認する場所

プルリクエストは、あるブランチの変更を別のブランチへ取り込むための提案です。略してPRと呼ばれます。ここに変更理由、対象、確認したことをまとめ、差分を見ながら相談します。PRを作っただけでは、変更が基準のブランチに取り込まれたことにはなりません。マージという統合操作が別にあります。

一人で作業している場合も、自分で差分を読み直す場所としてPRを使えます。作業しているときは見落とした誤字や、関係のないファイル変更を発見できることがあります。ただし、自分のPRを正式なレビュー承認で承認することはできません。一人の練習ではセルフチェックを行い、実務で必要な第三者レビューの代わりになったとは考えないようにします。

公式Hello Worldガイドも、リポジトリ、ブランチ、コミット、PRという順で基本を説明しています。この記事の旅行メモを一度終えたら、公式の別の題材でも同じ関係が分かるか試してください。画面の位置を暗記しただけなのか、作業の意味を理解できたのかを確かめる練習になります。

最初の到達点を具体的に決める

今回の完成条件は、READMEに旅行準備の三項目があり、追加した一項目の差分をPRで説明でき、mainへ取り込まれたことを確認できる状態です。コミットの数や見た目のにぎやかさを目標にしません。ファイルを編集できたことと、その変更がどこへ残ったかを説明できることの両方を目指しましょう。

途中で分からなくなったら、「今いるリポジトリの所有者」「選択中のブランチ」「変更したファイル」「コミットしたか」「PRの状態」の五つを書き出します。この情報があると、画面を無作為に開き直すより、次に確認する場所を選びやすくなります。慣れないうちはメモを横に置いて構いません。急いで操作することより、対象を間違えないことが大切です。

練習用リポジトリを作る｜公開範囲と最初のファイルを決める

自分のアカウントで練習する場所を用意する

GitHubへサインインし、新しいリポジトリを作成する画面を開きます。Ownerが自分の個人アカウントかを確認してください。会社やチームのOrganizationへ所属していると、所有者を選べる場合があります。権限があるからといって、組織の場所を個人の練習に使ってよいとは限りません。今回のような課題は、許可された自分の練習場所で行います。

リポジトリ名は「travel-checklist-practice」のように、用途が分かる英数字とハイフンの名前にします。説明欄には「架空の旅行準備メモで変更履歴を練習する」などと書けます。顧客名や実際の予定を名前に含める必要はありません。リポジトリ名や説明も、公開範囲に応じて人から見える情報だという意識を持ちましょう。

アカウントがまだない場合は公式の登録手順と利用条件を確認し、自分で管理できるメールや認証手段を用意します。認証コードや回復コードは他人へ渡さず、アカウントの安全を確保してください。既存の仕事用アカウントを使うか個人用を使うかは、会社の方針に合わせます。この記事は登録情報や秘密情報を入力する練習ではありません。

Privateを選び、共有先を増やさず始める

学習の途中経過を世界へ公開する必要がないなら、最初はPrivateで作ると範囲を限定しやすくなります。Publicは広く閲覧され得る状態で、Privateはアクセスを認めた範囲に限定する設定です。ただし、Privateなら秘密情報を無条件に置いてよいわけではありません。サービス上へ保存すること自体が、所属先の情報管理規則に関わる場合があります。

公式のリポジトリ作成手順では、Owner、名前、公開範囲、READMEなどの初期項目を指定する流れを確認できます。今回の練習ではREADMEを追加して作成します。すでに手元にあるGitリポジトリを取り込む手順とは条件が違うので、既存プロジェクトの移行時に同じ初期化を無条件で行わないでください。

ライセンスや.gitignoreは、意味が分からないまま何となく選ぶ必要はありません。公開して他人に利用してもらうコードならライセンスの検討が重要ですが、私的な短いメモの課題とは別の判断です。会社や他人が権利を持つ内容へ、自分の判断でライセンスを付けないようにしましょう。外部アプリへのアクセス追加や、自動生成の機能も、今回の基本操作には不要です。

※表は横にスクロールできます。

READMEを開き、表示と編集の違いを見る

作成後にREADME.mdを開きます。READMEは、リポジトリの目的や使い方を説明するファイルとしてよく使われます。拡張子の.mdはMarkdownという文章の書き方を示します。見出しや箇条書きを記号で表せますが、最初の練習では複雑な表や装飾を作る必要はありません。読み手が何の練習か分かる短い文があれば十分です。

表示画面と編集画面を切り替えると、同じファイルでも見え方が変わります。編集画面では記号を含む原文、プレビューでは整形された表示を見られます。記号が消えたのではなく、表示方法が違うと理解してください。ファイルを変更する前に、いま見ているブランチ名も確認します。READMEという同じ名前のファイルが、ブランチごとに異なる内容になることがあります。

初期のREADMEには「これはGitHub操作を練習するための架空の準備メモです」「持ち物：水筒」「持ち物：充電器」という程度の内容を置く課題にします。本名、実際の出発日、自宅住所、航空券の予約番号などは不要です。練習で使わない情報を入れないことが、後から消す方法を覚えるより確実な予防になります。

作成後の確認で、想定した場所かを照合する

リポジトリの所有者と名前、Privateの表示、READMEの存在を確認します。URLのアカウント部分も、自分の意図した場所かを見てください。ブラウザーで複数のアカウントやタブを使っている場合、別の場所で編集していることがあります。新しいタブを開き直しても同じリポジトリへ戻れるよう、名前と場所を控えておきましょう。

ここまでの操作で、まだ他人を招待する必要はありません。共同作業を試したい場合は、参加してもらう相手と目的、閲覧・編集の範囲を決めてから行います。リンクを送れば必ずPrivateの中を見られるわけではなく、権限が必要です。見られないと言われたときに、すぐPublicへ変えるのではなく、意図した共有方法を確認してください。

ブランチで変更を保存｜差分とコミットの意味を確かめる

mainから作業用ブランチを作る

基準のmainを表示し、ブランチ選択から「add-rain-item」などの作業用ブランチを作ります。名前は今回の変更目的に合わせます。ブランチを作った直後は、分岐元と同じ内容が見えるのが自然です。何も変わっていないから失敗したのではなく、ここから別の流れで変更を記録する準備ができた状態です。

作成後にブランチ名が切り替わっていることを確認してからREADMEを編集します。名前だけ作り、表示はmainのままで作業すると、意図した分離ができません。画面の上部で選択中のブランチを毎回見る習慣を付けてください。特に複数のタブを開くと、それぞれが違うブランチを表示している場合があります。

既存の共同開発では、作業用ブランチをどの基準から作るかも重要です。古い状態から始めると、他の人の変更を見落としたり競合が増えたりします。今回の新規メモならmainを基準にできますが、実務では開発用、リリース用など別のブランチを使うこともあります。見慣れた名前を勝手に正解として選ばず、チームの指定を確認します。

一つの目的に絞ってREADMEを編集する

作業用ブランチのREADMEへ「持ち物：雨具」という一行を追加します。同時にタイトルを全面変更したり、無関係な画像を追加したりせず、最初は一つの目的だけに絞ります。変更が小さければ、後で差分を見たときに何が起きたか分かりやすくなります。一つのPRへ関係のない変更を詰め込むと、確認や取り消しの判断が難しくなります。

プレビューで文章の表示を見た後、変更前後の差分を確認します。追加した行だけか、元の水筒や充電器が消えていないかを見ましょう。改行の変更で多くの行が差分になる場合もあります。見た目が同じだから問題ないと片付けず、本当に必要な変更かを確かめます。文章の編集でも、コードのレビューと同じように対象を限定する練習ができます。

画像やファイルのアップロードを使う場合は、選んだフォルダー全体を安易に追加しないでください。ダウンロードした資料、認証用のファイル、個人情報を含むスクリーンショットが混ざることがあります。今回の課題ではブラウザーで短い文章を直接編集するだけなので、ローカルのファイル一式を送る必要はありません。

コミットメッセージで変更を説明する

Commit changesの操作へ進み、「雨具を持ち物に追加」のように何を変えたか分かるメッセージを付けます。「修正」「更新」だけでも記録はできますが、あとで履歴を見たときに目的を探しにくくなります。短くても変更の対象と内容が分かれば十分です。必要なら、天候にかかわらず準備項目を確認できるようにした、といった理由を補足します。

コミット先が作業用ブランチであることを確認して確定します。ブラウザーの編集欄に文章を入れただけでは、履歴への記録は完了していません。確定後にREADMEを再表示し、追加した行とコミットの情報を確認します。ブラウザーの戻るボタンで古い表示が残る場合もあるため、最新の画面を読み込み直して照合しましょう。

コミットは変更を記録する操作で、PRの承認やマージとは違います。また、ブラウザーで直接コミットした今回の変更はGitHub側にあります。別にPCへクローンを持っていたとしても、その手元のファイルが自動で同じ内容になるとは限りません。次にローカルの作業を学ぶときは、取得と送信の操作を別に覚える必要があります。

※表は横にスクロールできます。

mainと作業用ブランチを往復して違いを見る

コミット後、mainへ切り替えてREADMEを確認します。まだPRをマージしていなければ、mainには雨具の行が入っていないはずです。再び作業用ブランチへ戻すと追加した行が見えます。これが今回確認したいブランチの分離です。「ファイルが消えた」と慌てる前に、どの流れを表示しているかを見ると状況を理解しやすくなります。

同じファイル名で内容が違うことに慣れたら、コミットの履歴から変更を開きます。誰が、いつ、どんな説明で、何を変えたかを追えることを確認しましょう。履歴を読む際は、古い時点のファイルを見ているのか、現在のブランチ先端を見ているのかも区別します。過去の画面を見ながら、最新の変更がないと誤解しないことが大切です。

プルリクエストを一巡する｜確認・修正・統合の流れ

baseとcompareを確認して提案を作る

作業用ブランチからPRを作成します。Compare & pull requestの案内が出ていればそこから進めますし、Pull requestsから新しいPRを作ることもできます。baseは取り込み先、compareは今回変更を作った側です。練習ではbaseをmain、compareをadd-rain-itemにそろえます。逆向きにすると、意図と違う変更を提案してしまうため、作成前に必ず確認してください。

公式のPR作成ガイドは、ブランチの選択と変更の提案を説明しています。差分がないと表示される場合は、同じブランチ同士を比べている、編集をコミットしていない、すでにマージ済みといった可能性があります。新しいファイルを無理に作って差分を発生させる前に、対象と履歴を確認しましょう。

タイトルは「旅行準備メモに雨具を追加」などとし、説明へ変更理由と確認内容を書きます。今回なら「持ち物一覧へ雨具を一行追加。既存の二項目は維持。READMEの表示と差分を確認」という内容で十分です。完成していない作業ならDraftを使える場合がありますが、Draftは秘密のPRという意味ではありません。リポジトリへアクセスできる人から見える範囲は別に管理されます。

Files changedで、説明と実際の変更を照合する

PRを作成したら、Conversationの説明だけでなくFiles changedを開きます。予定したREADMEだけが変わっているか、雨具の行が追加されているか、無関係な削除がないかを確認します。PRの説明は書いた人の説明であり、差分そのものではありません。「一行追加」と書いてあっても、実際の変更が同じとは限らないため、両方を照合します。

コメントは、相手の意図を確認したい箇所や修正が必要な箇所へ具体的に付けます。練習なら「雨具は折りたたみ傘を想定する、と書くと内容が具体的になりそう」というセルフチェックを記録できます。ただし、実務では要求なのか提案なのか質問なのかを分かるように書き、目的のない細かな好みで相手の作業を増やさない配慮も必要です。

コードを扱うPRでは、差分が読みやすいことと、プログラムが正しく動くことは別です。自動テストがある場合は結果を確認し、ない場合に「何も失敗していないからテスト済み」と表現しないでください。今回の文章課題では、文章の表示と変更内容を確認したと記録します。実行していないプログラムの動作確認まで行ったことにしないことが大切です。

修正は同じ作業ブランチへ追加する

レビューで「雨具の例を補足したい」と気づいたら、同じ作業用ブランチのREADMEを編集し、追加のコミットを作ります。PRはそのブランチの変更を追うので、修正のたびに新しいPRを作る必要はありません。コミット後に元のPRを開き、追加した修正が差分へ反映されていることを確認してください。

別のブランチへ誤って修正した場合、その変更は意図したPRへ自動で入るとは限りません。画面上で似た名前のブランチを選んでいないかを見ます。共同作業では、レビューのコメントへ「該当箇所を修正し、表示を再確認した」と短く返すと、確認する人が状況を追いやすくなります。コメントを解決済みにする操作と、実際のコードや文章の修正は別の行為です。

一人の練習でも、修正前後の差分を読み直してから進みましょう。誰かが承認したという表示がないことを、不具合と考える必要はありません。リポジトリの保護ルールにより承認が必要な場合は、そのルールに従います。マージしたいからと、必要なレビューやチェックを解除して通すことを通常の手順として覚えないでください。

※表は横にスクロールできます。

マージ後はmainの内容まで確認する

問題がないことを確かめ、練習用リポジトリでマージを行います。利用できるマージ方法は設定によって異なり、マージコミット、Squash、Rebaseなどがあります。最初は表示された方法の意味と、チームが使う方法を確認し、違いを理解しないまま本番で切り替えないようにします。今回の小さな課題では、取り込み先へ意図した文章が入ったかを確かめることが中心です。

PRがMergedと表示された後、mainへ戻ってREADMEを開きます。雨具の行と補足が入り、元の二項目が残っていることを確認します。PRの画面が閉じたことだけでは完了としません。Closedは取り込まずに閉じた場合にも使われるため、Mergedかどうかを見分けます。PRの状態と、最終的なファイルの中身の両方を見る習慣を付けてください。

使い終わった作業ブランチは、統合済みで今後使わないことを確認して整理できます。ただし、ほかの作業が乗っているブランチを名前だけで削除しないでください。マージ後にブランチを消すことは、PRの記録やmainへ取り込んだ内容を元に戻す操作とは違います。取り込み後に直したい点があれば、改めて小さな変更を作る方が分かりやすい場合があります。

間違いと共有範囲を点検｜秘密情報・競合・次の練習

間違った文章の修正と、秘密情報の漏えいは別に対処する

単なる誤字なら、新しいコミットで直し、必要に応じてPRで確認できます。一方、パスワードやAPIキー、トークンなどを誤って記録した場合、現在のファイルから消すだけでは十分ではありません。履歴や複製に残る可能性があるためです。秘密情報そのものをコメントへ貼り直して相談することも避け、まずアクセスを止める対応を優先します。

GitHub公式の機密情報削除ガイドは、秘密の失効・変更を先に行い、必要な履歴対応を慎重に進める考え方を示しています。仕事の情報なら担当者へ速やかに連絡し、組織の手順に従ってください。履歴の書き換えは他の人の作業にも影響するため、検索で見つけた強制操作を独断で実行しないことが重要です。

.gitignoreは、追跡しないファイルを指定するための仕組みですが、すでにコミットした秘密を履歴から消す機能ではありません。後から無視対象へ足したので漏えいも解決した、と判断しないでください。最初から練習には架空の内容だけを使い、公開して困るものを入れないことが基本です。PrivateからPublicへ変更する際も、現在の内容だけでなく履歴を含めて確認する必要があります。

競合は、どちらの内容を残すかを決める場面

複数のブランチで同じ行を違う内容へ変えると、マージ時に競合が起きることがあります。GitHubが自動で選べないため、人が最終的な内容を決める必要がある状態です。競合は、必ず誰かの操作ミスを意味するものではありません。先に変更した方が正しい、後から変更した方が正しいとも限らないので、両方の目的を確認します。

今回のメモを使うなら、片方が「雨具：傘」、もう片方が「雨具：レインコート」と同じ行を変えた場面を想像できます。目的が違えば「天候に応じて傘またはレインコートを用意」のように統合する判断もあります。ただし、これは文章の架空例です。プログラムでは両方を残すだけで動作が壊れる場合があるため、仕様とテストを含めた確認が必要です。

公式の競合解説によると、ブラウザーで解決できるものと、ローカルのGitクライアントなどが必要なものがあります。画面に解決ボタンがないときに、保護設定を外したり無理な上書きをしたりせず、扱える範囲を確認してください。競合を解消した後も、最終的な文章や動作を見直す工程は残ります。

マージを戻すときは、影響する変更を確認する

マージ後に問題が分かった場合、単純な再修正でよいのか、そのPRを取り消す必要があるのかを判断します。GitHubには、マージ済みPRをRevertするための機能がありますが、状況によっては自動で戻せません。また、取り消しは秘密情報を履歴から消す操作ではありません。何を戻したいのかを明確にし、ほかの変更への影響を確認して進めます。

公式のPRを戻す手順を参照し、権限と適用条件を確かめてください。実務では、戻した結果として別の機能や説明が古くなることもあります。元のPRだけを見て判断せず、その後の変更や運用状況を確認する必要があります。練習段階では、通常の修正PRをもう一度作ることから経験を増やすとよいでしょう。

Fork・Clone・Download ZIPを混同しない

ForkはGitHub上で別の所有者のもとに派生したリポジトリを作る操作、Cloneは履歴を含む作業用のコピーをPCなどへ取得する操作です。Download ZIPは、その時点のファイルをまとめて取得する用途で、通常のGit履歴を持つクローンとは異なります。どれも「コピー」に見えますが、その後に履歴を追い、変更を戻す方法が違います。

他人の公開リポジトリを読めることと、自由に改変・再配布できることも同じではありません。ライセンスと利用条件を確認し、貢献するときはCONTRIBUTINGなどの案内に従います。自分の練習のために、無関係なプロジェクトへテストのPRやIssueを送らないでください。共同作業の操作を試すなら、自分の練習用リポジトリや参加が明示された教材を使います。

取得したコードを実行する際は、READMEにあるコマンドだから安全と決めつけず、出所と内容を確認します。自動処理や外部連携に資格情報を与えることは、ファイルを読むこととは別の判断です。最初の文章課題では実行環境もトークンも不要なので、必要のない権限を増やさず、変更とレビューの流れを身に付けましょう。

次は小さな修正を、理由と確認結果付きで繰り返す

今回の課題を終えたら、別の一項目を追加する、見出しを読みやすくする、誤字を直すなど、もう一度小さなPRを作ってみます。そのたびに目的、差分、確認結果を説明できるかを振り返ります。PRの数を増やすだけでなく、他の人が読んで判断できる情報を残す練習が、共同作業につながります。

PC側のエディターで編集したい場合は、その次にClone、ローカル保存、コミット、push、更新の取得を学びます。ブラウザーだけの練習で分かった「どのブランチへ、何を記録するか」という考え方は、そのまま役立ちます。道具を増やす前に、現在どこに最新の変更があるかを説明できるようにしてください。

コードの書き方やレビューを継続して学びたい場合は、副業向けプログラミングスクールの料金・学習支援比較で、質問や添削の範囲を整理できます。GitHubの操作ができるだけで仕事や収入が保証されるわけではありません。まず小さな変更を安全に届けられるようになり、自分に不足している学習や支援を具体的に選びましょう。