マージ
複数人が別々に進めた変更を 1 つにまとめて統合すること。Gitなどのバージョン管理で、各自が作業した内容(ブランチ)を本流に取り込む操作を指す。CMS サイトの改修でも、複数のコーダーが同時並行で別ページを直し、それを本番反映用のソースに統合する、といった場面で使われる。
マージは「誰の変更が最終か」を明確にする運用の要。本番への直接編集と Git 経由の変更が混在すると、マージ時に本番直接編集分が上書きされ「データの先祖返り」が起きる。変更は必ずバージョン管理経由に統一し、本番を直接触らないルールが、マージ事故を防ぐ前提になる。
実務の論点はコンフリクト(同じ箇所を別々に編集した衝突)の解消・マージ前のレビュー・本番直接編集の禁止・マージ後の動作確認・リリースとの連動。担当者自身がマージ操作をすることは少ないが、「なぜ自分の修正が消えたのか」を理解するうえでこの概念は欠かせない。
落とし穴は、本番への直接編集分を業者のマージで上書きして先祖返りさせること。ほかにも、コンフリクトを安易に片方優先で解消して必要な変更を消す、マージ後の確認を怠ってデグレード、レビューなしで本流にマージして不具合混入、といった点に注意する。問題時はロールバックで戻す。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- バックエンドエンジニア
- Web 担当者(発注側)
- 情シス
- ディレクター
会話上での使用例
自分の修正が消えた原因を尋ねる場面
-
Web 担当者
先週直したはずの文言が、元に戻っています
-
コーダー
本番を直接編集された分が、業者側のマージで上書きされたパターンです。今後は変更を Git 経由に統一し、本番直接編集はやめましょう
並行作業の統合を確認する場面
-
Web 担当者
2 人が別ページを同時に直していますが、ぶつかりませんか
-
コーダー
別ページならマージで問題なく統合できます。同じ箇所を触る場合だけコンフリクトが出るので、その時はレビューして解消します