ソースコード修正の競合と統合

複数の案件が同時に動いており、1つのソースコードを複数の案件で修正する場合、ソースコード修正の競合(コンフリクト)の統合(マージ、差分取り込み)が必要になります。
統合には、全体のロジックの整合性や案件のリリース時期の違いを考慮する必要があり、機械的に判断できない場合もあるので、最終的には人の手で判断し統合する必要があります。


例えば、商品の販売価格を計算する以下のソースコードがあるとします。
(今回はjavaのソースコードであると仮定します)

・修正前ソース

このソースコードについて、下記3案件で修正するものとします。
案件1.消費税増税対応(3ヶ月後リリース)
案件2.店舗毎セール対応(3ヶ月後リリース)
案件3.タイムセール対応(6ヶ月後リリース)

3案件の修正後ソースはそれぞれ以下の通りとします。

・案件1

・案件2

・案件3

リリースすることを考えると、以下の2段階に分けてソースコードの修正を統合する必要があります。

・3ヶ月後を想定

 案件1と案件2を統合

・6ヶ月後を想定

 3ヶ月後のソースと案件3を統合


案件1と案件2の統合は容易です。
以下のように機械的に統合することができます。

・3ヶ月後のソース

対して、3ヶ月後のソースと案件3を統合は機械的に行うことができません。
修正ポイント2-5と修正ポイント3-4は同じ個所を修正しているので、両方の修正が反映されるようにソースを書き変えなければなりません。
そもそも、修正ポイント2-3でコンストラクタが追加になっているため、新たに追加したコンストラクタに対しても案件3の内容を反映しなければなりません。
よって、6ヶ月後のソースは以下のようになります。

・6ヶ月後のソース


なお、バージョン管理システムのGitのブランチやマージの機能を使えば、これらの統合の作業が楽になります。
機械的に統合できる箇所は自動で統合できますし、機械的に統合できないブランチについても以下のような方法を用いて比較的容易に統合することができます。
(具体的な操作方法は省略します。操作方法はWebで調べられるので、必要に応じて調べると良いでしょう。)

  • Gitが出力した差分を見てエディタで編集
  • 競合の原因となったコミットを取り消しコミットし直し
  • マスター管理しているブランチを元に新たにブランチを作り直し、作り直したブランチに対して同じ修正を行う

いかがでしたでしょうか。

「ソースコード修正の競合と統合」と言うと、Gitのテクニックが求められるように思われるかもしれません。
しかし、Gitの操作が多少不得手でも、何をしなければならないのかが理解できていれば、多少手間取ったり非効率になったりすることはあっても、最終的には問題無く修正作業を行うことができます。
まずは、何をしなければならないのかを理解することに努めましょう。
(それを理解する上で、今回の記事が参考になれば幸いです)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA