「ファイルを直したら、Gitで共有しておいて」と言われても、何から始めればよいか迷いますよね。
Gitで変更を共有するときは、ファイルを保存し、変更を確認して履歴に記録したあと、共有先へ送ります。それぞれの操作で、変更した内容の扱いが一段階ずつ進みます。
この記事では、プロジェクトの説明文を一文直す例で、作業の準備から共有・確認依頼までの流れを説明します。まずは「どこで、何のために操作するのか」を追いながら読んでみてください。実際に操作を試したい方のために、入力する指示と結果の確認方法も紹介します。
💡 このページでわかること
- Gitで変更を記録し、共有するまでの順番
- 保存・ステージング・コミット・プッシュの違い
- 操作ごとに何を確認すればよいか
Gitとは？ファイルの変更を履歴に残す道具
Git（ギット）は、ファイルの変更を履歴として記録し、あとから確認できる道具です。
たとえば、説明文を直したときに「何をどう直したか」を記録しておくと、あとから変更前と変更後を比べられます。
こうしたファイルや履歴は、リポジトリと呼ばれる保管場所で管理します。自分のPCにあるリポジトリで変更を記録し、チームで使う共有先のリポジトリへ送ることで、ほかの人にも内容を見てもらえます。
この記事では、GitHub（ギットハブ）というサービスを使って、ファイルや履歴を共有する例を紹介します。GitHubでは、共有した内容をオンラインで確認したり、変更についてメンバーと相談したりできます。
Gitを使うときの全体の流れ
基本の流れは、作業の準備 → ファイルの変更・確認 → 記録する内容の選択 → 履歴への記録 → 共有先への送信 → 確認依頼です。
特に、次の4つを分けて考えると、今どこまで進んだかをつかみやすくなります。
| 操作 | 何をする？ | この例での状態 |
|---|---|---|
| 保存 | 編集した内容をファイルに保存する | 自分のPCのファイルが変わった |
| ステージング | 次の記録に含める内容を選ぶ | 記録の準備ができた |
| コミット | 選んだ内容を履歴に記録する | 自分のPCに履歴が残った |
| プッシュ | 記録した履歴を共有先へ送る | GitHub側でも変更を確認できるようになった |
この4つを手がかりに、以降の手順で変更がどのように記録・共有されるかをたどっていきましょう。
例で見る：説明文を直して共有する6ステップ
今回は、プロジェクトの説明を書く README.md（リードミー）というファイルを使います。「このサイトは、IT用語を紹介します。」を「このサイトは、IT用語を初心者向けに紹介します。」へ直す例です。文章の小さな修正を通して、Gitで変更を扱う流れを見ていきましょう。
この例では、自分のPCで編集・記録を行い、GitHubの画面で共有した内容を確認します。まずは各STEPの説明と、「操作するとどうなるか」に注目してください。
実際に試す場合の準備
操作も試す方は、次の準備が済んだ環境を使いましょう。
- PCでGitを使えるようにする：Gitをインストールします。この例では、ブランチを切り替える
git switchが使える2.23以降を使います。 - 記録者の情報を設定する：変更の履歴に「誰が記録したか」を残すため、Gitに名前とメールアドレスを設定します。
- GitHubへ接続できるようにする：GitHubのアカウントを用意し、PCからファイルや履歴を送受信するときに、本人であることを確認する設定を済ませます。この本人確認を「認証」と呼びます。記録者の情報は履歴に名前を残すため、認証は接続する人を確認するためのものです。
- 練習用のリポジトリを用意する：GitHub上にREADME.mdが履歴として記録されていて、自分が変更を送れる場所を使います。仕事では、チームが指定したリポジトリと手順を確認しましょう。
準備をこれから行う方も、先にこの記事で全体の流れをつかんでおくと、各設定の目的を理解しやすくなります。
手順中の git status などの文字は、Gitにしてほしいことを伝える指示で、「コマンド」と呼びます。文字で指示を入力する画面「ターミナル」に1行ずつ入力し、Enterキー（MacではReturnキー）で実行します。入力した行の下に表示される結果を読んでから、次へ進みましょう。表示例は英語ですが、環境によって日本語などで表示されることもあります。エラーが出たときは、いったん操作を止めて表示内容を確認します。
STEP1：作業するファイルを自分のPCに用意する
初めて参加するプロジェクトでは、共有先からファイルや履歴を自分のPCへ複製します。この操作をクローンといいます。
GitHubの対象リポジトリで「Code」を開き、取得用URLをコピーします。このURLは、複製元のリポジトリの場所をGitに伝えるためのものです。HTTPS・SSHという接続方法の選択肢があるので、準備のときに設定した方法を選びましょう。
次に、ターミナルで保存先のフォルダーを開き、次の形で実行します。保存先の開き方は使うアプリによって異なります。職場の手順書などを使う場合は、指定されたターミナルとフォルダーを確認してください。
git clone "取得用URL" git-practice
cd git-practice1行目の git clone で、共有先のファイルや履歴が自分のPCへ複製されます。取得用URL はコピーした実際のURLに置き換え、git-practice という名前のフォルダーを新しく作ります。同名のフォルダーがない場所で実行してください。
2行目の cd git-practice は、ターミナルで操作する場所を、今作ったフォルダーへ移す指示です。これで、その中のファイルをGitのコマンドで確認できるようになります。
以降のコマンドは、この git-practice フォルダー内で実行します。すでにプロジェクトをクローンしてある場合は、同じものを作り直さず、その作業フォルダーを開きます。
次に、現在の状態を確認します。
git statusOn branch main なら、現在は main という名前のブランチにいます。ブランチは、変更の履歴の流れを分けて作業する仕組みです。元になるブランチの名前は、プロジェクトによって異なります。
nothing to commit, working tree clean は、通常の設定では、Gitの確認対象に未記録の変更がない状態を表します。ここで見ているのは自分のPC側の状態です。共有先への送信が済んだか、共有先に新しい変更があるかは、別に確認します。
なお、Gitの確認対象から外す設定にしたファイルや、編集アプリで保存する前の内容は、この表示の確認範囲に含まれません。
作業を始める前から変更済みのファイルが出ている場合は、その内容を確認してから進みます。別の作業の変更を、今回の記録へ混ぜないためです。
以前クローンしたものを使うときは、作業を分ける前に、チームの手順で元になるブランチを最新にします。「どのブランチから始めればよいですか。最新にする手順も教えてください」と確認すると進めやすくなります。
STEP2：今回の変更用にブランチを作る
ブランチを作ると、元の履歴から分かれた流れに、今回の修正を記録できます。あとで変更内容を確認してから元のブランチへ取り込めるよう、作業用ブランチを用意しましょう。STEP1で確認した、チーム指定のブランチから始めます。
git switch -c docs/readme-intro
git statusdocs/readme-intro は、今回のブランチに付けた名前です。git switch -c は、新しいブランチを作り、そのブランチへ切り替える指示です。
On branch docs/readme-intro と表示されれば、切り替えができています。仕事ではブランチ名の付け方にもルールがあるため、指定に合わせます。
同名のブランチがすでにあるというエラーが出た場合は、そこに残っている作業を確認してから、今回使うブランチ名を決めましょう。
STEP3：ファイルを変更し、内容を確認する
クローンしたフォルダーを、普段使う文章・コード編集用のアプリで開きます。その中のREADME.mdにある説明文を直し、ファイルを保存してください。
変更前の例：
このサイトは、IT用語を紹介します。変更後の例：
このサイトは、IT用語を初心者向けに紹介します。続いて、ターミナルで変更を確認します。
git status
git diffgit status では、変更したファイルの一覧を確認できます。README.mdが変更済みとして表示されているかを見ます。
git diff では、保存したファイルと、記録対象として選んだ内容との差を確認できます。こうした違いを「差分」と呼びます。この時点では、README.mdの修正内容が表示されます。今回のような文章の変更では、行頭の - が変更前、+ が変更後の内容を表します。
表示のうち、文章を比べる部分は次のようになります。
-このサイトは、IT用語を紹介します。
+このサイトは、IT用語を初心者向けに紹介します。「初心者向けに」という言葉だけが意図どおり追加され、関係のない文章まで変わっていないことを確認しましょう。長い表示から入力画面へ戻れないときは、q キーで表示を閉じられる場合があります。
なお、新しく作ったファイルは、通常の git diff には表示されません。git status の Untracked files（まだGitの管理対象になっていないファイル）に出ている場合は、編集アプリでも中身を確認します。
STEP4：今回記録する内容を選ぶ
内容を確認できたら、次に履歴へ記録する内容を選びます。この準備がステージングです。今回は「README.mdの説明文を直した」というひとまとまりの変更を記録対象にします。その選んだ内容を履歴に残す操作が、次のSTEPで行う「コミット」です。
git add README.md
git diff --staged
git statusgit add README.md は、その時点のREADME.mdの内容を記録対象として用意します。新しいファイルを追加するときだけでなく、既存ファイルの修正にも使います。
git diff --staged では、次のコミットに入る変更を確認できます。git status の Changes to be committed（次のコミットに含める変更）に、今回記録したいファイルだけがあることも確認しましょう。
git add のあとに文章を直した場合、その修正を含めるには、もう一度 git add が必要です。 Gitは、addした時点の内容を記録対象として保持します。追加で直したら、保存 → add → git diff --staged での確認、という順に進めましょう。
STEP5：変更をコミットして履歴に残す
記録対象を確認できたら、変更の説明を付けて履歴に残します。この操作がコミットです。
git commit -m "READMEの紹介文に対象読者を追記"
git log -1 --oneline
git status-m の後ろにある引用符内の文章は、変更内容を説明する「コミットメッセージ」です。「修正」だけより、何を変えたのか分かる文章にすると、あとから探しやすくなります。
git log -1 --oneline は、現在のブランチの直近のコミットを1件、短く表示します。今入力した説明が出ていれば、記録を確認できます。
README.md以外に変更がなく、すべて記録できていれば、git status は未記録の変更がない状態になります。これで、自分のPCに修正の履歴が残りました。次は、その履歴をGitHubへ送ります。
STEP6：GitHubへ送り、変更を確認してもらう
履歴を共有先へ送る操作がプッシュです。この例では、作業用ブランチをGitHubへ送ります。
git push -u origin docs/readme-introこのコマンドは、「今回の作業用ブランチを、登録されている共有先へ送る」という指示です。それぞれの指定には、次の意味があります。
origin：通常のクローンで登録される共有先の呼び名。docs/readme-intro：送る作業用ブランチの名前。-u：自分のPCのブランチと、GitHub側の対応するブランチを結び付けて記憶させる指定。
送信が成功したら、Webサイトを見るためのアプリ「ブラウザー」でGitHubのリポジトリを開きます。ブランチの選択欄で docs/readme-intro に切り替えると、今回送った側の内容を見られます。README.mdに「初心者向けに」が加わっていることと、コミットの記録を確認しましょう。
チームでの作業なら、続いてプルリクエストを作ります。これは「この変更を元のブランチへ取り込んでよいか、確認してください」という提案です。
GitHubで「Compare & pull request」などから作成画面を開き、base（取り込み先）がチーム指定のブランチ、compare（変更元）が docs/readme-intro になっているか確認します。案内が表示されない場合は、「Pull requests」から「New pull request」を開きます。変更一覧も見直し、次のように説明すると確認する人に伝わります。
変更内容：READMEの紹介文に「初心者向けに」を追記しました。
理由：サイトの対象読者が伝わるようにするためです。
確認したこと：文面と差分を確認し、ほかの箇所に変更がないことを確認しました。作成後は、チームの方法で確認担当者に依頼します。変更を確認して意見をもらうことを「レビュー」、ブランチの変更を別のブランチへ取り込むことを「マージ」といいます。レビューは内容の確認、マージは取り込みの操作であり、別の役割です。
ここまでを整理すると、プッシュは作業用ブランチの共有、プルリクエストは取り込みの提案、マージは元のブランチへの取り込みです。マージは、必要な確認を終え、チームのルールに従って行います。
初心者が注意するポイント
記録・共有する前に、対象のファイルを確認する
最初は git add README.md のように、対象を指定すると確認しやすくなります。まとめて選ぶ操作では、関係のないファイルまで記録対象に入ることがあるためです。
パスワードや接続用の秘密情報は、非公開のリポジトリであってもコミットしないようにします。一度履歴に残すと、あとからファイル内の文字を消しただけでは、過去の記録から消えません。
プログラムを変えたときは、動作も確認する
Gitで履歴に残す作業とあわせて、変更内容が意図どおりかを自分でも確かめます。
今回は説明文の修正なので文面を確認しました。プログラムを変えた場合は、決められた方法で画面や処理の動きも確認し、その結果をプルリクエストに書きましょう。
送信に失敗したら、エラーを読んで状況を確認する
プッシュは、接続の認証、権限、共有先の更新などが原因で失敗することがあります。送れなかったからといって、すぐに強制送信へ切り替えないでください。共有済みの履歴を書き換え、ほかの人の作業に影響する場合があります。
仕事なら「このコマンドを実行すると、このメッセージが出ました」と、実行した指示とエラー内容を添えて相談します。共有する画面や文章に秘密情報が含まれていないかも確認してください。
よくある疑問
コミットしたのにGitHubへ反映されないのはなぜ？
自分のPCでコミットしただけでは、GitHubへ送られていないためです。プッシュの成功と、GitHubで見ているブランチを確認しましょう。
また、working tree clean は自分のPC側の変更状態を示します。プッシュの完了を示すものではありません。
プルとプルリクエストは同じもの？
別のものです。プルは、共有先の変更を取得し、現在の作業ブランチへ取り込むGitの操作です。プルリクエストは、ブランチの変更を取り込むための提案・相談です。
プルでは、自分とほかの人の変更が重なり、自動で取り込めない場合があります。この状態を「競合」といいます。どちらの内容を残すか判断する必要があるため、初めて遭遇したときはチームに相談しましょう。
コマンドを使わないとGitは操作できない？
ボタンやメニューから操作できるアプリもあります。見た目が違っても、変更を確認し、記録対象を選び、コミットして共有する考え方は同じです。
プッシュやマージをすると、本番のサイトも変わる？
プロジェクトの設定によります。共有先への送信やブランチへの取り込みと、利用者が使う本番サイトへの反映は、役割が異なります。
ただし、プッシュやマージをきっかけに自動で反映する仕組みもあります。仕事で使うときは、どの操作で本番へ反映されるのかを最初に確認してください。
まとめ
Gitを初めて使うときは、変更を確認する → 記録対象を選ぶ → コミットする → プッシュするという順番を押さえましょう。
作業を始める前には、対象のリポジトリとブランチを確認します。共有後はGitHub上でも変更を確認し、必要に応じてプルリクエストでレビューを依頼します。
今回の例では、一文の修正が「PCのファイルの変更」から「履歴の記録」、そして「GitHubで確認できる変更」へと進みました。実際に試すときも、この流れを思い出しながら、一つずつ結果を確かめてみてください。
関連記事
- GitとGitHubの違いとは？初心者向けにやさしく解説：変更を記録する道具と、共有・相談する場所の役割を整理したい方へ。
- ターミナルとは？黒い画面で何ができるのかを初心者向けに解説：コマンドを入力する画面の役割や、最初の操作から知りたい方へ。