Gitのpull・push・mergeの違いとは？「サーバーに上げる＝マージ」ではない理由をSVNとの違いも含めて解説

GitやSubversion（SVN）などのバージョン管理を使っていると、「pull」「push」「merge」「commit」「update」など似た場面で使う用語が多く、現場ごとに言い回しが違って混乱することがあります。

特に「プログラムをサーバーに上げることをマージと呼ぶのか」という点は、GitとSVNの概念を分けて理解すると整理しやすくなります。結論として、merge（マージ）はTortoiseSVNだけの用語ではありません。Gitにも正式なmergeがあります。ただし、単純にファイルやコミットをサーバーへ送る操作をmergeとは通常呼びません。

この記事では、Gitのpull・push・mergeがそれぞれ何をしているのか、SVNやTortoiseSVNとの違い、そして現場で誤解されにくい言葉の使い分けを具体例付きで解説します。

Gitの「merge」は複数の開発履歴を統合する操作

Gitにおけるmergeは、あるブランチの変更履歴を別のブランチへ統合する操作です。Gitの正式なコマンドとしてgit mergeが存在します。

たとえばfeature/loginというブランチでログイン機能を開発し、その変更をmainブランチへ取り込む場合、この操作は「feature/loginをmainへマージする」と表現できます。

具体的には、mainブランチへ移動したあとにgit merge feature/loginを実行すれば、feature/login側の履歴を現在のブランチへ統合します。

[参照] Git公式ドキュメント「git-merge」

「サーバーに上げる」操作はGitでは通常pushと呼ぶ

ローカル環境で作成したGitのコミットを、GitHub、GitLab、Bitbucket、社内Gitサーバーなどのリモートリポジトリへ送信する操作は、通常pushと呼びます。

たとえばローカルのmainブランチのコミットをoriginというリモートへ送るなら、git push origin mainのように実行します。

このため「自分のPCやLinux環境にある変更履歴をGitサーバーへ送った」という意味なら、「サーバーにマージした」より「pushした」と表現するほうがGitの用語として正確です。

[参照] Git公式ドキュメント「git-push」

pushとmergeは何が違うのか

pushとmergeは、似たタイミングで行われることがありますが、役割はまったく異なります。pushは「リポジトリ間でコミットを送る操作」、mergeは「異なる履歴を一つに統合する操作」です。

たとえば「プログラムを修正→commit→push」という流れでは、mergeを一度も行わないことがあります。反対にローカル環境だけで二つのブランチを統合することもでき、その場合はmergeをしてもpushしないことがあります。

pullの中でmergeが行われることがある

混乱しやすい理由の一つが、git pullの内部でmergeが行われる場合があることです。

Gitのpullは、基本的にはリモートから変更を取得するfetchと、その変更を現在のブランチへ統合する処理を組み合わせた操作です。設定によってはmergeではなくrebaseが使われることもあります。

つまり「pullした結果、リモート側の変更と自分の変更がマージされた」という表現はあり得ます。しかし「pullそのもの」と「merge」は厳密には同じ意味ではありません。

[参照] Git公式ドキュメント「git-pull」

具体例で見るGitの一連の流れ

たとえばLinux上でソースコードを修正し、Gitサーバーへ送る一般的な流れを考えてみます。

git add .で変更をステージし、git commit -m "修正内容"でローカルリポジトリへ記録し、その後git push origin mainでリモートへ送ります。

この一連の作業は「変更をコミットしてpushした」と表現するのが自然です。単に「マージした」と言うと、聞いた側は「別ブランチを統合したのだろう」と解釈する可能性があります。

GitHubやGitLabのPull Requestを取り込む場合はmergeと言える

一方で、GitHubやGitLabなどでは、開発ブランチをmainブランチへ取り込む際にPull RequestやMerge Requestを使います。この処理を完了することは一般的に「マージする」と呼ばれます。

たとえば開発者がfeatureブランチをpushし、レビュー後にPull Requestをmainへ統合した場合、「PRをマージした」という表現は正確です。

ここでは「サーバー上で操作した」という点ではpushと似ていますが、実際に行っている処理は別ブランチの履歴統合なのでmergeです。

「サーバーに上げる」が何を意味するかで用語が変わる

日本の開発現場では「サーバーに上げる」という表現が非常に広く使われますが、実際にはいくつか異なる操作を指す可能性があります。

したがって「サーバーへ上げる」という言葉だけでは、Gitサーバーへのpushなのか、本番サーバーへのdeployなのかを区別できません。チーム内では具体的な操作名を使うほうが安全です。

本番サーバーへプログラムを置くことは通常deployと呼ぶ

Gitリポジトリではなく、Webサーバーやアプリケーションサーバーなど実際の実行環境へプログラムを配置する場合は、一般的には「deploy（デプロイ）」と呼びます。

たとえばGitのmainブランチへmergeしたあと、CI/CDによって本番サーバーへアプリケーションが配置されるなら、「mainへマージしたあと本番へデプロイされた」という表現になります。

現場ではこの一連の作業をまとめて「本番へ上げる」と呼ぶこともありますが、Gitのmergeとは別概念です。

mergeはTortoiseSVNだけの用語ではない

mergeという操作はTortoiseSVN独自のものではありません。Subversionにも正式にmergeという概念があり、Gitにも存在します。

TortoiseSVNはSubversionをWindowsのエクスプローラーから操作しやすくするGUIクライアントです。そのメニューに「Merge」があるため、TortoiseSVN特有の言葉のように見えることがありますが、実際にはSubversion自体が持つ機能をGUIから実行しています。

Apache Subversionの公式ドキュメントでも、ブランチ間の変更を統合する操作としてmergeが説明されています。

[参照] Version Control with Subversion「Basic Merging」

SVNとGitでは「サーバーへ反映」の考え方が違う

GitとSVNの用語が混ざりやすい理由として、両者の仕組みそのものが異なることも挙げられます。

SVNは集中型バージョン管理システムです。通常、commitすると中央リポジトリへ直接変更が記録されます。一方Gitは分散型なので、commitはまず自分のローカルリポジトリへ記録され、リモートへ送るには別途pushが必要です。

たとえばGitでは「commitしたけれどまだpushしていない」という状態が普通に存在します。SVN中心の経験が長い場合、この二段階の仕組みが用語の混乱につながることがあります。

GitとSVNの主要用語を比較

両者を単純に一対一対応させることはできませんが、概念を整理するために大まかに比較すると次のようになります。

この表を見ると分かるように、mergeはGitにもSVNにもあります。一方、pushは分散型であるGitを理解するうえで重要な操作です。

コマンドラインかTortoise系GUIかは用語の意味に関係しない

Linuxのコマンドラインを使うか、TortoiseSVNのようなGUIを使うかによってmergeの意味が変わるわけではありません。

GUIは操作方法を視覚化したものです。Gitでもgit mergeとコマンドラインから実行できますし、SourceTreeやGitKrakenなどのGUIクライアントからmergeすることもできます。

したがって「Tortoiseだからマージ、Linuxコマンドだからマージではない」という区別ではありません。重要なのは、何のツールを使っているかではなく、実際に何の処理をしているかです。

現場で誤解を防ぐおすすめの言い方

開発現場では用語の厳密さだけでなく、相手と同じ意味で理解できることが重要です。そのため操作名を具体的に伝えるのがおすすめです。

たとえば「ソースをサーバーに上げました」より「mainブランチへpushしました」、「マージしました」より「featureブランチをmainへmergeしました」と言えば、何をしたのか明確になります。

本番環境の場合も「サーバーに上げました」ではなく、「本番へデプロイしました」「リリースしました」と言えば、Gitのpushやmergeと区別できます。

「マージ」という言葉が広い意味で使われる現場もある

実務では、会社やチーム独自の言葉遣いが定着しているケースもあります。「成果物を本流へ取り込む一連の作業」をまとめて「マージ」と呼ぶ現場もあり得ます。

そのような社内用語が必ず間違いというわけではありません。ただしGitの標準用語として考えれば、mergeはブランチなどの履歴を統合する操作を指します。

他部署や新しいメンバー、外部ベンダーと会話するときには、標準的なGit用語へ合わせたほうが認識違いを減らせます。

merge conflictはpushの失敗とは別物

mergeを理解するうえで知っておきたいのが「コンフリクト」です。二つの履歴で同じ箇所が異なる内容に変更されている場合、Gitが自動的に統合できずmerge conflictが発生することがあります。

たとえばmainブランチでは設定値をAからBへ変更し、featureブランチでは同じ行をAからCへ変更していた場合、どちらを採用すべきかGitだけでは判断できません。

この状態を人間が修正してからmergeを完了します。これは「サーバーへファイルを送れなかった」というpushエラーとは性質が異なります。

まとめ：Gitでは「送る＝push」「統合する＝merge」と覚えると分かりやすい

Gitにおけるmergeは、別ブランチなどの変更履歴を現在のブランチへ統合する操作です。TortoiseSVNだけの用語ではなく、GitにもSubversionにも正式に存在します。

一方、ローカルリポジトリのコミットをGitサーバーへ送る操作は通常pushと呼びます。本番のWebサーバーやアプリケーションサーバーへプログラムを配置する作業であれば、deployやリリースという言葉が適しています。

簡単に整理すると、「記録する＝commit」「リモートへ送る＝push」「リモートから取得・反映する＝pull」「履歴を統合する＝merge」「実行環境へ配置する＝deploy」と覚えておくと混乱しにくくなります。

GitとSVNでは仕組みが異なるため、長くSVNを使っていた場合に言葉の感覚がずれることは珍しくありません。重要なのは経験年数やGUI・コマンドラインの違いではなく、その場で行っている処理を具体的な用語で表現することです。