マージ

複数人が別々に進めたプログラムやデザインの変更を、1 つにまとめて「統合」することです。Git(ギット)などのバージョン管理システムにおいて、各自が枝分かれして作業した内容(ブランチ)を、メインとなる本流に取り込む操作を指します。CMS サイトの改修などで、複数のエンジニアが同時並行で別々のページを作り、最終的に本番反映用のデータ(ソース)としてガッチャンコする場面で使われます。

現場の鉄則：「先祖返り」を防ぐため本番環境は絶対に直接触らない

マージは「誰の変更が最終的な正解か」を確定させる運用の要です。

ここで絶対にやってはいけないのが「本番環境への直接編集」です。「ちょっとした文字修正だから」と本番サーバーのファイルを直接書き換えてしまうと、後日業者が Git 経由で最新の改修データを「マージ」した瞬間に、あなたの直接編集分が上書きされて消滅し、古い状態に戻ってしまう「データの先祖返り」という大事故が起きます。変更は必ずバージョン管理(Git)を経由させ、本番は直接触らないというルールが、マージ事故を防ぐ大前提です。

実務の論点と「プルリクエスト」

Web 担当者自身がマージのコマンドを打つことは稀ですが、「なぜ自分の修正が反映されないのか」を理解する上で欠かせない概念です。

実務では、いきなりマージするのではなく、制作会社から「作業が終わったのでマージしても良いか確認してね」という申請が出されます。これを「プルリクエスト(PR)」と呼び、ここでコードの内部レビューを行ってから初めて本流にマージされるのが正常なフローです。

現場でよくある「痛い失敗」とトラブル

コンフリクト(衝突)の適当な解消：「A さんが文字を直し、B さんが同じ行の色を変えた」ように、同じ箇所を別々に編集して統合しようとすると、システムが判断できずコンフリクト(衝突エラー)が起きます。これを安易に「A さん優先」で強制解消し、B さんの必要な変更まで消してしまう人為的ミスに注意が必要です。
デグレード(品質悪化)の発生：マージ後の動作確認を怠った結果、他の箇所に影響が出て「以前直したはずのバグが復活する(デグレード)」リスクがあります。
非常時のロールバック：レビューなしで本流にマージして不具合が混入した場合、慌てず速やかにマージ前の状態に「ロールバック(巻き戻し)」する手順を業者と握っておくことが重要です。

言葉をよく利用する人

コーダー / フロントエンドエンジニア
バックエンドエンジニア
Web 担当者(発注側)
情シス
ディレクター

会話上での使用例

先週直したはずの文言が元に戻っていて、原因をコーダーに尋ねる場面

Web担当者
先週直したはずの文言が、なぜか元に戻ってしまっています。
コーダー
本番を直接編集された分が、こちらのマージで上書きされたパターンですね。今後は変更をすべてバージョン管理経由に統一して、本番の直接編集はやめておきましょう。
Web担当者
なるほど、それで消えたんですね。直接編集はやめるルールにします。

2人が別ページを同時に直していて、衝突しないか確認する場面

Web担当者
2人が別々のページを同時に直しているのですが、ぶつかったりしませんか。
コーダー
別のページならマージで問題なく統合できます。同じ箇所を触ったときだけ衝突が起きるので、その場合はレビューして解消します。
Web担当者
別ページなら大丈夫なんですね。安心しました。