バージョン管理ツールの運用

A社は，業務システムの開発を行う企業で，システムの新規開発のほか，リリース後のシステムの運用保守や機能追加の案件も請け負っている。A社では，ソースコードの管理のために，バージョン管理ツールを利用している。

バージョン管理ツールには，1人の開発者がファイルの編集を開始するときにロックを獲得し，他者による編集を禁止する方式（以下，ロック方式という）と，編集は複数の開発者が任意のタイミングで行い，編集完了後に他者による編集内容とマージする方式（以下，コピー・マージ方式という）がある。また，バージョン管理ツールには，ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能がある。以降，分岐元，及び分岐して管理される，変更内容の履歴をブランチと呼ぶ。

ロック方式では，編集開始時にロックを獲得し，他者による編集を禁止する。編集終了時には変更内容をリポジトリに反映し，ロックを解除する。ロック方式では，一つのファイルを同時に1人しか編集できないので，複数の開発者で開発する際に変更箇所の競合が発生しない一方，^①開発者間で作業の待ちが発生してしまう場合がある。

A社では，規模の大きな改修に複数人で取り組むことも多いので，コピー・マージ方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツールでは，開発者は，社内に設置されているバージョン管理ツールのサーバ（以下，サーバという）のリポジトリの複製を，開発者のPC上のローカル環境のリポジトリとして取り込んで開発作業を行う。編集時にソースコードに施した変更内容は，ローカル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内容は，編集完了時にサーバのリポジトリに反映させる。サーバのリポジトリに反映された変更内容を，別の開発者が自分のローカル環境のリポジトリに取り込むことで，変更内容の開発者間での共有が可能となる。

コピー・マージ方式では，開発者間で作業の待ちが発生することはないが，他者の変更箇所と同一の箇所に変更を加えた場合には競合が発生する。その場合には，ソースコードの変更内容をサーバのリポジトリに反映させる際に，競合を解決する必要がある。競合の解決とは，同一箇所が変更されたソースコードについて，それぞれの変更内容を確認し，必要に応じてソースコードを修正することである。

A社で使うバージョン管理ツールの主な機能を表1に示す。

注記　A社では，ローカル環境での変更内容を，サーバのリポジトリに即時に反映させるために，コミット又はマージを行ったときに，併せてプッシュも行うことにしている。

〔ブランチ運用ルール〕

開発案件を担当するプロジェクトマネージャのM氏は，ブランチの運用ルールを決めてバージョン管理を行っている。取り扱うブランチの種類を表2に，ブランチの運用ルールを図1に，ブランチの樹形図を図2に示す。

クリックで拡大

図2　ブランチの樹形図

〔開発案件と開発の流れ〕

A社が請け負ったある開発案件では，A，B，Cの三つの機能を既存のリリース済のシステムに追加することになった。

A，B，Cの三つの追加機能の開発を開始するに当たり，開発者2名がアサインされた。機能AとCはI氏が，機能BはK氏が開発を担当する。開発の流れを図3に示す。

クリックで拡大

図3　開発の流れ

I氏は，機能Aの開発のために，ローカル環境でaブランチからfeature-Aブランチを作成し開発を開始した。I氏は，機能Aについて(ア)，(ウ)，(オ)の3回のコミットを行ったところで，(ウ)でコミットした変更内容では問題があることに気が付いた。そこでI氏は，(α)のタイミングで，^②(ア)のコミットの直後の状態に滞りなく戻すための作業を行い，編集をやり直すことにした。プログラムに必要な修正を加えた上でcした後，^③テストを実施し，問題がないことを確認した。その後，レビューを実施し，aブランチにマージした。

機能Bは機能Aと同時に開発を開始したが，規模が大きく，開発の完了は機能A，Cの開発完了後になった。K氏は，機能Bについてのテストとレビューの後，ローカル環境上のaブランチにマージし，サーバのリポジトリにプッシュしようとしたところ，競合が発生した。サーバのリポジトリからaブランチをプルし，その内容を確認して競合を解決した。その後，ローカル環境上のaブランチを，サーバのリポジトリにプッシュしてからテストを実施し，問題がないことを確認した。

全ての変更内容をdevelopブランチに反映後，releaseブランチをdevelopブランチから作成して^④テストを実施した。テストで検出された不具合を修正し，releaseブランチにコミットした後，再度テストを実施し，問題がないことを確認した。修正内容をaブランチとbブランチにマージし，bブランチの内容でシステムの運用環境を更新した。

〔運用ルールについての考察〕

feature-Bブランチのように，ブランチ作成からマージまでが長いと，サーバのリポジトリ上のdevelopブランチとの差が広がり，競合が発生しやすくなる。そこで，レビュー完了後のマージで競合が発生しにくくするために，随時，サーバのリポジトリからdevelopブランチをプルした上で，^⑤ある操作を行うことを運用ルールに追加した。