記事一覧 Git とは？ GitHub との違いと、コミット／プッシュ／プル／マージの意味
コーディング

Git とは？ GitHub との違いと、コミット／プッシュ／プル／マージの意味

Git とは？ GitHub との違いと、コミット／プッシュ／プル／マージの意味
会社の Web 担当になって、半年が経った。
ある朝、こたつがメールを開くと、ホームページを頼んでいる制作会社から、短い連絡が届いていた。
「GitHub にプッシュしました。main にマージしておきます」
3回、読み直した。
それでも、意味が分からなかった。
こたつは、制作会社の雲龍先生に電話をかけた。
こたつ（Web担当） 雲龍先生、今朝の連絡なんですが……。
プッシュ？ マージ？
ホームページは、もう直ったということでしょうか。
雲龍先生（制作会社のエンジニア） まだ、ホームページが変わったとは限りません。
どちらも、Git という仕組みの言葉です。
順番に説明しますね。
この連絡が、何のことか分からない——。
そんな方に向けて、Git の仕組みと、よく出てくる言葉をまとめました。
コマンドの例も載せていますが、VS Code などのアプリなら、同じ操作を画面のボタンで行えます（よくある質問）。
目次

Git とは

ファイルの変更の履歴を残す仕組み

Git（ギット）は、ファイルの変更の履歴を残しておく仕組みです。
ファイルを直したら、区切りの良いところで「ここまで」と記録します。
すると、いつ／誰が／何を変えたかが、1回毎に残ります。

例えば、先週直したトップページを、元に戻したくなったとします。
Git なら、先週の状態をそのまま取り出せます。
2つの時点を並べて、どこが変わったかを比べることも出来ます。

このような仕組みを、バージョン管理と言います。
Git は、Linux を作った Linus Torvalds 氏が、2005年に Linux の開発のために作りました。
Git の前にも、Subversion（SVN）などの、同じような仕組みがありました。
今では、ホームページやアプリを作る人の多くが、Git を使っています。
Git そのものは無料で、Windows／Mac／Linux のパソコンで使えます。
こたつ（Web担当） 先週の状態を、そのまま取り出せる……。
実は先月、古いファイルで上書きしてしまって、元に戻すのに半日かかったんです。
あの日の冷や汗を、こたつは今でも覚えている。
雲龍先生（制作会社のエンジニア） Git で履歴を残しておけば、次からは、前の状態を取り出すだけで済みますよ。

バージョン管理の方法

こたつ（Web担当） でも、前の版を残すだけなら、ファイル名を変えておけば良いのでは？
うちの共有フォルダにも、「index_最新.html」がいくつもあります。
雲龍先生（制作会社のエンジニア） 「最新」がいくつもある時点で、どれが本当の最新か、もう分からなくなっていますね。
こたつは、返す言葉が無かった。
前の版を残す方法には、いくつかの種類があります。
ここでは、共有フォルダ／共同編集／Git の3つを比べます。
共有フォルダと共同編集は、ホームページに限らず、普段の仕事のファイルでも使う方法です。
ブランチとマージは、作業を分けて進め、後で合わせる仕組みです（ブランチで作業を分ける）。
それぞれを、最新版の管理方法／修正履歴の残り方／差分（前の版から変わった所）の見つけ方／ブランチとマージが出来るかの4つで比べると、次のようになります。
共有フォルダに置く
交代で直す（社内のサーバーなど）
最新版
ファイル名で見分ける
（ファイルが増えていく）
修正履歴
残らない
差分
自分で見比べる
ブランチとマージ
出来ない
共同編集する
同時に直す（Google ドキュメントで書く、ホームページの原稿など）
最新版
1つのファイルのまま
修正履歴
自動で残る
（区切りは無い）
差分
版を開いて見比べる
（Google ドキュメントは色で分かる）
ブランチとマージ
出来ない
（全員が同じ版を直す）
Git を使う
ホームページのファイル（GitHub など）
最新版
1つのファイルのまま
修正履歴
区切り毎に残す
（説明を付けて記録）
差分
変わった行が分かる
（前の版との違いだけを表示）
ブランチとマージ
出来る
（作業を分けて進め、仕上がったら合わせる）
図1：前の版を残す3つの方法

共同編集との違い

こたつ（Web担当） うちは、Google ドライブで共同編集もしています。
それで十分な気もしますけど……。
雲龍先生（制作会社のエンジニア） Word や Excel なら、それが一番だと思います。
ただ、ホームページのファイルには、Git の方が向いている所があるんです。
共同編集と Git は、どちらも修正履歴が残りますが、次の6つが違います。
区切り
共同編集は、直すたびに、自動で保存が続きます。
Git は、「ここまで」を自分で決めて、説明を付けて記録します（コミット）。
そのため、意味のある区切りで、前の状態に戻したり、比べたり出来ます。
作りかけ
共同編集では、全員が同じ1つの版を直します。
作りかけの状態も、すぐに全員に見えます。
Git では、ブランチで作業を分けて進め、仕上がってから合わせます。
みんなで使っている版に、作りかけが混ざりません。
ファイルの数
共同編集の履歴は、ファイル1つ毎に残ります。
Git は、HTML／CSS／画像など、複数のファイルの変更を、1つの記録にまとめられます。
同じファイルを同時に直した時
Google ドキュメントは、同時に直しても、その場で1つにまとまります（Dropbox など、ファイルを同期するだけのサービスでは、「競合コピー」という別のファイルが出来ます）。
Git では、それぞれが分かれて直し、後で合わせます。
離れた所の変更なら、自動で合わせられます。
同じ所を別々に直した時は、コンフリクトになって止まります（コンフリクト）。
他の人に届く時
共同編集は、保存した瞬間に、全員のファイルが変わります。
間違えて消したファイルも、すぐに全員のところから消えます。
Git では、コミットしてプッシュするまで、他の人には届きません。
間違えても、自分のパソコンの中で止まります。
向いているファイル
Google ドライブなどの共同編集やファイルの共有は、Word／Excel／画像／動画など、文字だけではないファイルに向いています。
Git は、HTML／CSS／プログラムなど、文字のファイルに向いています。
画像も置けますが、どこが変わったかまでは分かりません。
動画のような大きなファイルを置くと、リポジトリが重くなります。
ホームページの制作でも、原稿は Google ドキュメントで一緒に直し、HTML／CSS は Git で管理する、というように、両方を使い分けています。
その代わり、Git には、覚える言葉と操作が多くあります。
この記事の後半（履歴を残す操作から）で、1つずつ紹介します。

Git と GitHub の違い

Git と GitHub は、名前が似ていますが、別のものです。
Git
自分のパソコンで動く、履歴を残す仕組みです。
インターネットに繋がなくても使えます。
GitHub
Git のリポジトリ（履歴の置き場）を、インターネット上に置くサービスです。
置いたリポジトリを、他の人と共有できます。
1人で履歴を残すだけなら、Git だけで足ります。
複数の人で同じファイルを直す時は、GitHub など、リポジトリを預かるサービスを一緒に使います。
プッシュしたファイルと履歴は GitHub などにも残るので、パソコンが壊れた時の控えにもなります（プッシュしていない変更は残りません）。
GitHub の他にも、同じようなサービスがいくつかあります（代表的なサービス）。

Git の全体の流れ

眼鏡の龍が結んだ巻物が、雲の上の GitHub の蔵へ飛んでいき、蔵から別の家の若い龍のもとへ届く浮世絵
送って、預けて、受け取る
直したファイルは、次の順番で、他の人に届きます。
自分のパソコンの中には、3つの場所があります。
そこで記録した履歴を、GitHub などのサービスを通して、他の人と共有します。
自分のパソコン
直して記録する
作業フォルダ
ファイルを直す
ステージ
記録するファイルを選ぶ
（add で載せる）
ローカル
リポジトリ
履歴に記録する
（commit で記録する）
プッシュ（push）で送る
GitHub などのサービス
履歴を共有する
リモートリポジトリ
みんなの履歴を置いておく
プル（pull）／クローン（clone）で受け取る
他の人の
パソコン
同じ履歴を受け取る
ローカルリポジトリ／作業フォルダ
履歴もファイルも、自分と揃う
図2：直したファイルが、他の人に届くまで

作業フォルダ／ステージ／リポジトリ

3つの場所の役割は、次の通りです。
作業フォルダ
普段、ファイルを開いて直すフォルダです。
Git の説明では「ワーキングツリー」とも言います。
ステージ
次の記録（コミット）に入れるファイルを、一旦置いておく場所です。
「インデックス」とも言います。
リポジトリ
記録した履歴をしまっておく場所です。
英語の repository（保管場所）から来た言葉です。
ホームページなら、普通はサイト1つ毎に、1つのリポジトリを作ります。
作業フォルダの中の .git という隠しフォルダが、リポジトリの中身です。
ステージは、何のためにあるのでしょうか。
例えば、3つのファイルを直している途中で、2つだけが仕上がったとします。
その2つだけをステージに載せて、先に記録します。
残りの1つは、直し終えてから記録できます。
ステージを使うと、このように、記録したいものだけを選べます。
こたつ（Web担当） 写真を撮る前に、写すものだけを台に並べるようなものですね。
雲龍先生（制作会社のエンジニア） その通りです。
コミットが写真を撮ること、ステージがその台だと思うと、覚えやすいですよ。

自分のパソコンのリポジトリと、サービスのリポジトリ

自分のパソコンにあるリポジトリを、ローカルリポジトリと言います。
GitHub などのサービスにあるリポジトリは、リモートリポジトリです。

コミットは、ローカルリポジトリにだけ記録します。
プッシュして送るまで、他の人のパソコンにも、GitHub のページにも出ません。
「コミットしたのに、GitHub に出ない」という時は、まだプッシュしていないことがほとんどです。

リポジトリと、ホームページのサーバー

電話を繋いだまま、こたつはブラウザで自社のホームページを開いてみた。
見たところ、何も変わっていない。
こたつ（Web担当） 「GitHub にプッシュしました」とあったのに、うちのホームページは、何も変わっていないんです。
雲龍先生（制作会社のエンジニア） GitHub に送っただけなので、ホームページはまだ変わりません。
GitHub などのリポジトリと、ホームページを公開しているサーバーは、別の場所なんです。
ホームページのファイルがある場所は、次の4つです。
GitHub などの
リポジトリ
非公開なら、許可した人だけが見る
リモートリポジトリ
ファイルと修正履歴の置き場
プッシュ（push）で送る
プル（pull）で受け取る
自分のパソコン
見るのは、自分だけ
作業フォルダ
ファイルを直す
サーバーにアップロードする（FTP など）
ホームページの
サーバー
ここに置いたものが、ブラウザに出る
テストサーバー
公開する前に、見た目を確かめる
（パスワードなどで、見る人を絞る）
本番サーバー
公開しているホームページ
（誰でも見に来る）
図3：リポジトリと、ホームページのサーバーの関係
テストサーバーや本番サーバーに出すには、別にアップロードします（FTP など）。

マージした時に、自動で本番サーバーに上げる仕組み（GitHub Actions など）にしている場合は、main へのマージが公開の合図になります。

履歴を残す操作

ここからは、自分で操作してみたい方に向けて、よく使う操作を、コマンドの例と合わせて紹介します。
連絡の意味だけを知りたい方は、ブランチで作業を分けるとまとめを読めば足ります。
コマンドは、Windows では Git Bash か PowerShell、Mac ではターミナルで実行します。
操作する時に要るもの
まず、自分のパソコンに Git を入れます（Mac は、初めて git を実行した時に、入れ方の案内が出ます）。
GitHub などのリポジトリを使う時は、そのサービスのアカウントと、リポジトリを使う権限が要ります。
権限は、リポジトリを管理している人（制作会社など）が付けます。
初めてクローンやプッシュをする時に、サービスへのログインを求められます。
Windows では、ログインの画面が出ます。
Mac のターミナルでパスワードを聞かれた時は、GitHub のパスワードではなく、GitHub の設定で作るトークン（パスワードの代わりの文字列）を入れます。
Windows の Git を新しい版にする方法は、Windows の Git をアップデートする方法で紹介しています。

リポジトリを作る／クローン（clone）

新しくリポジトリを作る時は、作業フォルダで次のコマンドを実行します。
フォルダの中に .git フォルダが出来て、Git で履歴を残せるようになります。
git init
GitHub などのサービスの上にリポジトリを作る時は、サービスの画面のボタン（GitHub では「New」）から作ります。
公開／非公開を間違えない
サービスの上にリポジトリを作る時は、公開（Public）か非公開（Private）かを選びます。
公開にすると、ファイルも修正履歴も、インターネットの誰でも見られます。
お客様のホームページのファイルや、社外に出せないファイルが入るリポジトリは、非公開にします。
後から非公開に直しても、公開していた間に誰かが複製したものは、消せません。
GitHub などにあるリポジトリを、自分のパソコンに複製することを、クローン（clone）と言います。
使うのは、リポジトリのページの「Code」（GitHub）や「Clone」（Bitbucket）のボタンで出る URL です。
その URL を付けて、次のように実行します。
履歴も丸ごと複製するので、クローンした後は、自分のパソコンで前の履歴を見られます。
git clone https://github.com/<アカウント名>/<リポジトリ名>.git

ステージ（add）

直したファイルを、ステージに載せることを、add（アド）と言います。
ステージに載せたファイルが、次のコミットに入ります。
git add index.html
git add .
1行目は、index.html だけを載せます。
2行目は、今いるフォルダの中で変えたファイルを、全て載せます（新しく作ったファイルも含みます）。
どのファイルを直していて、どれを載せたかは、git status で分かります。

コミット（commit）

ステージに載せた変更を、履歴として記録することを、コミット（commit）と言います。
コミットには、名前とメールアドレスが残ります。
そのため、初めて使う時に、次のように登録しておきます。
git config --global user.name "Taro Yamada"
git config --global user.email "taro@example.com"
コミットする時は、何をしたかの説明（コミットメッセージ）を付けます。
git commit -m "お知らせのページを足す"
-m は、message（メッセージ）の頭文字で、続く " " の中がコミットメッセージになります。
-m を付けないと、メッセージを書くための画面（エディタ）が開きます。

コミット毎に、日時／名前／メッセージが残ります。
コミットを見分けるための ID（3f2a9c1 のような英数字）も付きます。
これまでのコミットの一覧は、git log --oneline で見られます。

メッセージには、何をどうしたかを書いておくのがおすすめです。
半年後に一覧を見返した時、「修正」としか書いていないと、どのコミットか分かりません。
「お問い合わせフォームの送信先を変える」と書いてあれば、すぐに見当が付きます。
こたつ（Web担当） 半年後の自分への、置き手紙ですね。
雲龍先生（制作会社のエンジニア） ええ。
それに、その手紙を読むのは、自分とは限りません。
担当が替わった後の、誰かかもしれないんです。
こたつは、前の担当者が残していったフォルダを思い出した。
何のためのものか分からないファイルが、今も並んでいる。

他の人と共有する操作

プッシュ（push）

ローカルリポジトリのコミットを、リモートリポジトリに送ることを、プッシュ（push）と言います。
プッシュすると、他の人もそのコミットを受け取れるようになります。
git push
新しく作ったブランチ（ブランチとは）を初めてプッシュする時は、送り先を付けて実行します。
origin は、クローンした元のリモートリポジトリの呼び名です。
-u は、upstream（上流）の頭文字です。
-u を付けておくと、手元のブランチと送り先のブランチが組になり、次からは git push や git pull だけで、同じ相手とやり取り出来ます。
git push -u origin add-news
こたつ（Web担当） もし、プッシュして英語のエラーが出たら……。
何か壊してしまったと思って、手が止まりそうです。
雲龍先生（制作会社のエンジニア） 「rejected」と出ることがありますが、何も壊れていません。
次の通りにすれば、大丈夫です。
他の人が先に同じブランチにプッシュしていると、「rejected」と出て、プッシュが止まります。
その時は、先にプル（pull）で他の人のコミットを受け取ってから、もう一度プッシュします。

プル（pull）とフェッチ（fetch）

リモートリポジトリにある他の人のコミットを、自分のパソコンに受け取る操作は2つあります。
フェッチ（fetch）
コミットを受け取るだけで、作業フォルダのファイルは変えません。
何が変わったかを、先に確かめたい時に使います。
プル（pull）
フェッチした後に、受け取ったコミットを今のブランチに合わせて、作業フォルダのファイルも新しくします。
合わせ方（マージかリベースか）は、Git の設定で変わります。
git fetch
git pull
作業を始める前に git pull で手元を最新にしておくと、他の人の変更とぶつかりにくくなります。
git pull が止まった時
自分と他の人の両方が、同じブランチに新しいコミットを足していることがあります。
Windows の Git は、入れた時の設定のままなら、マージして合わせます。
合わせ方を選ぶ設定が無い Git では、git pull が止まり、「divergent branches」や「Not possible to fast-forward」と出ます。
止まった時は、マージで合わせるなら git pull --no-rebase を、リベースで合わせるなら git pull --rebase を実行します（マージとリベースの使い分け）。

ブランチで作業を分ける

main の旗の立つ川が中州で2本に分かれ、眼鏡の龍が作りかけのお知らせのページを描く舟と、別の龍が直し終えたページを掲げる舟が進み、直しの舟が先に本流へ合流する浮世絵
分かれて直し、仕上がったら合流

ブランチ（branch）とは

ブランチ（branch）は、履歴の流れを枝分かれさせて、作業を分ける仕組みです。

例えば、お知らせのページを新しく作っている途中に、急ぎの文字の直しを頼まれたとします。
お知らせのページは、まだ仕上がっていません。
ここで2つの作業を別のブランチに分けておくと、文字の直しだけを、先に main へ合わせられます。

GitHub などで作ったリポジトリの、初めからあるブランチは main です（古いリポジトリや、パソコンで git init したリポジトリでは、master のこともあります）。
作業は別のブランチで進めて、仕上がったものだけを main に合わせる、という使い方が多いです。
git switch -c add-news
git switch main
git branch
1行目は add-news というブランチを作って切り替え、2行目は main に戻ります。
1行目の -c は、create（作る）の頭文字です。
3行目はブランチの一覧を出します（今いるブランチに * が付きます）。
古い説明では、1行目を git checkout -b add-news と書いていることもあります（同じ操作です）。
こたつ（Web担当） 急ぎの直しって、作りかけの時に限って来るんですよね。
雲龍先生（制作会社のエンジニア） ええ、本当に。
ブランチは、そういう時のためにあるんです。
雲龍先生の声には、実感がこもっていた。

マージ（merge）

ブランチで進めた作業を、別のブランチに合わせることを、マージ（merge）と言います。
add-news の作業を main に合わせる時は、main に切り替えてから実行します。
git switch main
git merge add-news
次の図で、A／B は、元からあるコミットです。
C／D は、add-news で足したコミットです。
E は、その間に、他の人が main に足したコミットです。
このように main にも新しいコミットがある時にマージすると、両方を合わせたマージコミット（M）が出来ます。
%%{init: {"gitGraph": {"rotateCommitLabel": false}, "themeVariables": {"git0": "#26265c", "git1": "#e8823a", "gitBranchLabel0": "#ffffff", "gitBranchLabel1": "#ffffff", "commitLabelColor": "#26265c", "commitLabelBackground": "#f2f1fa", "commitLabelFontSize": "14px"}}}%%
gitGraph
  commit id: "A"
  commit id: "B"
  branch add-news
  checkout add-news
  commit id: "C"
  commit id: "D"
  checkout main
  commit id: "E"
  merge add-news id: "M"
図4：マージ（add-news の C／D と、main の E を、マージコミット M で合わせる）
では、main に新しいコミットが無い時は、どうなるでしょうか。
その時は、普通はマージコミットを作りません。
main が、add-news の先まで進むだけです。
これを、早送りのマージ（fast-forward）と言います。

コンフリクト（同じ所を2人が直した時）

雲龍先生（制作会社のエンジニア） 同じ見出しを、2人が別々の言葉に直したとします。
この2つを合わせると、どうなると思いますか？
こたつ（Web担当） 後から合わせた方が勝つ、とか……？
雲龍先生（制作会社のエンジニア） どちらも勝ちません。
Git はそこで止まって、どちらを残すかを、人に選ばせるんです。
黙って片方を消してしまうことは無い。
こたつには、それが誠実な仕組みに思えた。
例えば、main では見出しを「お知らせ」に直し、add-news では、同じ見出しを「ニュース」に直したとします。
この2つをマージすると、コンフリクト（conflict／衝突）が起きて、マージが止まります。
同じ行が、違う内容に直っているためです。
すぐ隣の行を直した時や、片方がファイルを消して、もう片方が同じファイルを直した時にも起きます。
どちらの内容を残すかは、人が選びます。
コンフリクトが起きたファイルには、次のような印が入ります。
index.html
<<<<<<< HEAD
<h2>お知らせ</h2>
=======
<h2>ニュース</h2>
>>>>>>> add-news
<<<<<<< HEAD から ======= までが、今のブランチ（main）の内容です。
======= から >>>>>>> add-news までが、合わせようとしたブランチの内容です。
残す方の内容に書き換えて、印の行を消してから保存します。
全てのファイルを直したら、add とコミットをすると、マージが終わります。
--no-edit を付けると、マージのメッセージが自動で付きます（付けないと、メッセージを書く画面が開きます）。
git add index.html
git commit --no-edit
VS Code では、印の上に出る「現在の変更を取り込む」「入力側の変更を取り込む」のボタンで、残す方を選べます。
マージをやめて、始める前の状態に戻す時は、git merge --abort を実行します。

プルリクエストで確かめてから合わせる

GitHub などのサービスには、ブランチを main に合わせる前に、他の人に変更を確かめてもらう機能があります。
GitHub／Bitbucket／Backlog では、プルリクエスト（pull request）と呼びます。
GitLab では、マージリクエスト（merge request）と呼びます。
プルリクエストは、Git の機能ではなく、サービスの機能です。
流れは次の通りです。
  1. 作業したブランチをプッシュする
  2. サービスの画面で、合わせる先（main）を選んで、プルリクエストを作る
  3. 他の人が、変わった行（差分）を見て、コメントを付けたり、承認したりする
  4. 画面のボタンで、main にマージする
GitHub のマージのボタンでは、合わせ方を次の3つから選べます。
リポジトリの設定で、使える合わせ方を絞っていることもあります。
  • マージコミットを作る（Create a merge commit）
  • コミットを1つにまとめる（Squash and merge）
  • リベースして合わせる（Rebase and merge）

代表的なサービス

Git のリポジトリを置いて共有するサービスで、代表的なものは次の4つです。
どれも中では同じ Git が動いているので、基本の操作は変わりません。
違いは、運営している会社と、組み合わせて使う他のサービスです。

GitHub

Microsoft が運営している、利用者が一番多いサービスです。
誰でも見られる形で公開しているプログラムも、その多くが GitHub にあります。
Git を使う人の多くが、GitHub のアカウントを持っています。

GitLab

GitLab 社が運営しているサービスです。
GitLab は、自社のサーバーに入れて使うことも出来ます。
そのため、プログラムを社外のサービスに置けない会社でも使えます。

Bitbucket

Jira／Confluence を作っている Atlassian 社のサービスです。
Jira の課題と、コミットやブランチを結び付けて見られます。
Jira で作業を管理している会社に向いています。

Windows のパソコンから https で繋いでいる場合は、注意が要ります。
2026年11月30日以降は、古い Git Credential Manager では、ログインと push／pull が出来ません（Windows の Git をアップデートする方法）。

Backlog

福岡のヌーラボ社が運営している、課題（やることの一覧）を管理するサービスです。
Git のリポジトリも使えます。
画面も問い合わせの窓口も日本語なので、制作会社とお客様が、課題のやり取りと Git を1か所で使う時に便利です。

他によく出てくる用語

ここまでに出てこなかった言葉で、よく目にするものは、次の通りです。
用語 意味
HEAD（ヘッド） 今いるブランチの、一番新しいコミットを指す印
タグ（tag） 公開した版（v1.0 など）の印として、コミットに付ける名札
スタッシュ（stash） コミットしていない変更を、一旦しまっておく機能
.gitignore Git で管理しないファイル（自動で出来るファイルや、各自のパソコンの設定ファイルなど）を書いておくファイル
フォーク（fork） GitHub などで、他の人のリポジトリを、自分のアカウントに複製すること
チェリーピック（cherry-pick） 他のブランチのコミットを1つだけ選んで、今のブランチに取り込むこと
.gitignore に書いても、既にコミットしたファイルは、履歴から消えません。
パスワードなどは、初めからリポジトリに入れないようにしておくと安心です。

作業の流れの例

ここまでの操作を、1つの作業の流れで並べると、次のようになります。
お問い合わせのページの文言を直す例です。
  1. main を最新にする
    git switch main で main に切り替え、git pull で他の人の変更を受け取ります。
  2. 作業用のブランチを作る
    git switch -c fix-contact で、ブランチを作って切り替えます。
  3. ファイルを直して、コミットする
    直したファイルを git add でステージに載せ、git commit -m "お問い合わせのページの文言を直す" で記録します。
    作業が長い時は、区切りの良いところで何回かに分けてコミットします。
  4. プッシュする
    git push -u origin fix-contact で、ブランチをリモートリポジトリに送ります。
  5. プルリクエストを作る
    GitHub などの画面で、fix-contact から main へのプルリクエストを作ります。
  6. 確かめてもらって、マージする
    他の人に変更を見てもらい、問題が無ければ、画面のボタンで main にマージします。
  7. 手元を片付ける
    git switch main と git pull で、手元の main を最新にします。
    使い終わったブランチは、git branch -d fix-contact で消します。
    「not fully merged」と出て消せないことがあります（Squash and merge や Rebase and merge で合わせた時に出ることがあります）。
    その時は、画面でマージ済みかを確かめてから、-d を -D に変えて消します。

リベース（rebase）

リベース（rebase）も、ブランチの作業を合わせる方法の1つです。
マージは、2つの流れを、マージコミットで1つに合わせます。
リベースは、ブランチで足したコミットを、合わせる先のブランチの、一番新しいコミットの後ろに付け直します。
add-news を main の最新の後ろに付け直す時は、add-news に切り替えてから実行します。
git switch add-news
git rebase main
次の図の C2／D2 は、C／D と同じ変更を、E の後ろに付け直したコミットです。
付け直したコミットは、元の C／D とは別のコミットになり、ID も変わります。
この後に main で git merge add-news を実行すると、早送りのマージになります。
履歴は、1本の線に並びます。
%%{init: {"gitGraph": {"rotateCommitLabel": false}, "themeVariables": {"git0": "#26265c", "git1": "#e8823a", "gitBranchLabel0": "#ffffff", "gitBranchLabel1": "#ffffff", "commitLabelColor": "#26265c", "commitLabelBackground": "#f2f1fa", "commitLabelFontSize": "14px"}}}%%
gitGraph
  commit id: "A"
  commit id: "B"
  commit id: "E"
  branch add-news
  checkout add-news
  commit id: "C2"
  commit id: "D2"
図5：リベース（add-news の C／D を、main の E の後に C2／D2 として付け直す）
リベースでも、コンフリクトが起きることがあります。
その時は、マージの時と同じようにファイルを直して、add します。
VS Code のボタンは、マージの時と逆になり、「現在の変更」が main 側、「入力側の変更」が自分のコミットになります。
その後、git rebase --continue で続けます（やめる時は git rebase --abort）。

マージとリベースの使い分け

マージとリベースの違いは、次の通りです。
マージ リベース
履歴の形 枝分かれとマージコミットが残る 1本の線に並ぶ
元のコミット そのまま残る 付け直して、ID が変わる
向いている場面 作業を終えたブランチを、main など他の人と共有しているブランチに合わせる時 自分だけが使っているブランチを、main の最新に合わせる時
迷った時は、元のコミットがそのまま残るマージを使うと安心です。
他の人と共有しているブランチはリベースしない
既にプッシュして、他の人も使っているブランチをリベースすると、他の人の手元の履歴と、リモートリポジトリの履歴が食い違います。
リベースは、まだプッシュしていないコミットか、自分だけが使っているブランチに使います。

よくある質問

FTP でアップロードするのと、何が違いますか？
FTP は、パソコンのファイルをサーバーに送って、上書きするだけの仕組みです。
前の状態や、誰がいつ直したかは残りません。
2人が同じファイルを上げると、後から上げた方だけが残ります。

Git は、履歴を残して共有する仕組みです。
ホームページをサーバーに公開する仕組みとは、別のものです（リポジトリと、ホームページのサーバー）。
Git の前は、どうやって履歴を残していましたか？
初めは、ファイル1つ毎に、前の版から変わった所（差分）を残す仕組みでした（1970〜80年代の SCCS や RCS）。
次に、その履歴をサーバーの1か所（リポジトリ）に集めて、複数の人で使えるようになりました（1990年ごろの CVS）。
ただ、記録はまだファイル毎で、まとめて直した変更も、ファイル毎にバラバラに残っていました。
2000年の SVN（Subversion）で、複数のファイルの変更を、1回の記録にまとめられるようになりました。

2005年の Git は、そのリポジトリを、一人一人のパソコンにも丸ごと持てるようにしました。
SVN と違い、サーバーに繋がっていなくても、自分のパソコンでコミット出来ます。
ブランチも、SVN より手軽に作って切り替えられます。
1回の記録では、全てのファイルの状態を写真のように残し、差分は、2つの記録を比べて出します。
コマンドを覚えないと使えませんか？
画面のボタンで操作できるアプリもあります。
VS Code では、「ソース管理」の画面で、add／コミット／プッシュ／プル／ブランチの切り替えが出来ます。
他に、GitHub Desktop や Sourcetree なども、無料で使えます。
どのアプリも、中では同じ Git が動いています。
この記事の言葉が分かれば、ボタンの意味も分かります。
間違えてコミットした時は、どうしますか？
まだプッシュしていない時は、直前のコミットを直したり、取り消したり出来ます。
git commit --amend -m "新しいメッセージ" は、直前のコミットのメッセージを書き直します。
ステージに載せた変更があれば、それも直前のコミットに足します。
git reset --soft HEAD~1 は、直前のコミットを取り消して、変更をステージに戻します。
HEAD~1 は、HEAD の1つ前のコミットのことです。

既にプッシュした時は、git revert <コミットの ID> で、そのコミットを打ち消すコミットを新しく作ります。
履歴を消さずに元に戻すので、他の人の手元の履歴と食い違いません。
プッシュした後で、リベースしても良いですか？
自分だけが使っているブランチなら、リベースした後に git push --force-with-lease で、リモートリポジトリの履歴を上書き出来ます。
--force-with-lease は、他の人が後からプッシュしたコミットがある時は止まるので、--force より安全です。
main など、他の人も使っているブランチでは、リベースも上書きのプッシュもしません（マージとリベースの使い分け）。

まとめ

こたつ（Web担当） 今朝の連絡の意味が、やっと分かりました。
「GitHub にプッシュしました」は、制作会社のパソコンで記録した変更を、GitHub に送ったということ。
「main にマージしておきます」は、作業したブランチを、main に合わせるということですね。
雲龍先生（制作会社のエンジニア） その通りです。
ホームページが変わるのは、その後にサーバーへ上げた時です（マージで自動で上げる仕組みなら、マージした時）。
こたつのアカウントも、リポジトリに招待しておきますね。
次に連絡が来たら、GitHub の履歴も開いてみてください。
何がどう変わったかを、自分の目で確かめられますよ。
Git は、ファイルの変更の履歴を残し、GitHub などのサービスを通して、複数の人で同じファイルを直せるようにする仕組みです。
基本の操作とコマンドは、次の通りです。
操作 コマンド すること
リポジトリを作る git init 今のフォルダで Git を使い始める
クローン git clone <URL> サービスのリポジトリを複製する
ステージ（add） git add <ファイル> 次のコミットに入れるファイルを選ぶ
状態を見る git status 直したファイルと、ステージに載せたファイルを見る
コミット git commit -m "<メッセージ>" 変更を履歴に記録する
履歴を見る git log --oneline コミットの一覧を見る
プッシュ git push コミットをリモートリポジトリに送る
フェッチ git fetch 他の人のコミットを受け取るだけ
プル git pull 他の人のコミットを受け取って、今のブランチに合わせる
ブランチを作る git switch -c <ブランチ名> ブランチを作って切り替える
マージ git merge <ブランチ名> 指定したブランチの作業を、今のブランチに合わせる
リベース git rebase <ブランチ名> 今のブランチのコミットを、指定したブランチの最新の後に付け直す
表の <…> には、実際の名前や URL を入れます。
こたつ（Web担当） それにしても、Git は、ホームページやシステムを作るエンジニアだけの道具だと思っていました。
雲龍先生（制作会社のエンジニア） 実は、そうでもないんです。
Word ではなく、文字だけのファイル（Markdown など）で書いた手順書なら、Git で履歴を残せます。
社内の手順書を、そうやって Git で管理している会社もありますよ。
電話を切った後、こたつは共有フォルダを開いた。
「業務マニュアル_最新」「業務マニュアル_最新2」「業務マニュアル_最新_確定」。
前の版の残し方を、一度考え直してみよう。
Git は、エンジニアだけのものではないのかもしれない。
こたつは、そう思い始めていた。
サイトの課題を、一緒に整理しませんか
IMG-flowは大阪のWeb制作会社です。
サイトの制作から公開後の運用改善まで、できることをサービスページにまとめています。
サービスを見る 相談だけでも受け付けています
この記事は参考になりましたか？
ご回答ありがとうございました
前の記事 パスワードが漏れていないか調べる方法　漏えいがわかった時にやること 次の記事 共有アカウントの2段階認証　Ente Authで複数人が同じ認証コードを使う方法
関連記事
共有アカウントの2段階認証　Bitwardenで複数人が同じ認証コードを使う方法 2026.11.06 共有アカウントの2段階認証　Bitwardenで複数人が同じ認証コードを使う方法 共有アカウントの2段階認証　Ente Authで複数人が同じ認証コードを使う方法 2026.11.06 共有アカウントの2段階認証　Ente Authで複数人が同じ認証コードを使う方法 パスワードが漏れていないか調べる方法　漏えいがわかった時にやること 2026.11.04 パスワードが漏れていないか調べる方法　漏えいがわかった時にやること
記事一覧へ戻る