(Photo by：Mark Hawkins)
はじめに
あなたの開発現場はどのバージョン管理システムを利用しているでしょうか。
ソフトウェアは年々その便利さや機能が進化していくのと同時に複雑さも増しています。
ソフトウェアはソースコードを含めたファイルの集合によって作られますが、そういったファイルの変更も頻繁に、しかも1人ではなく、複数人によって行われます。
そうなると大変となるのがソースコードの変更を管理することです。
この記事では、バージョン管理システムの導入を検討している方のために、いくつかのバージョン管理システムの概要と特徴を組込みエンジニアの観点からお伝えします。
バージョン管理システムとは？
冒頭でお伝えしたように、バージョン管理システムとは、ファイルの変更を管理するものです。
いつファイルが作られたのか、どこが誰によって変更されたのか、その履歴を管理することはソフトウェア開発において、とても重要なことです。
ソフトウェアに何か重要な問題が発生したときに、過去の状態に戻して確認が必要なこともあるでしょう。そういったときに過去の状態に戻す作業はバージョン管理システムがなければ大変です。変更を行った本人でさえも、当時のソースコードを再現することは難しいかもしれません。私自身、携帯電話のソフトウェア開発プロジェクトにいたときは、数年前(プロジェクト参画前)に作られたソースコード、しかも何度も改変が行われたソースコードを読む必要がありました。このように、途中からプロジェクトに参画したメンバーであっても過去の変更された経緯を把握することはとても重要です。
また、同じソースコードに対して複数人が同時に作業を行ってしまうと、最新版がどれなのか分からなくなってしまう問題も発生します。
バージョン管理システムは、このような問題を解決する仕組みを提供するものでもあります。
バージョン管理システムを大きく大別すると、
- ローカル・バージョン管理システム
- 集中バージョン管理システム
- 分散バージョン管理システム
の3つに分けられます。この3つの内、現在主流となっているのが③で、②も使われることがあります。②③の代表的なものを以下でご紹介します。
Gitの概要
Git公式サイト：https://git-scm.com/
GitはもともとLinuxカーネルの開発者の間で作られた分散バージョン管理システムです。
Gitに限らずですが、分散バージョン管理システムで重要なのは「リポジトリ」という概念です。このリポジトリに全てのファイルの変更履歴が管理されています。
リポジトリには、個人のコンピュータ内部に作るローカルリポジトリと複数人で共有するリモートリポジトリの2種類があります。
分散バージョン管理システムの真骨頂としては「ブランチ」が挙げられるでしょう。ブランチとは、変更履歴の流れを枝のように分岐して記録していくためのものです。私がいた組込みソフトソフトウェア開発プロジェクトにおいても、リリース用のブランチとバグ修正用のブランチに分けて、次のリリースの前にブランチ同士をマージさせるという作業を行っていました。この仕組みによって、リリース版に対して行われた変更の影響を受けることなくバグ修正に取り組むことができます。逆もまた然りで、バグ修正の影響がリリース版に及ぶ前(マージ前)にテストを行うことができます。
デメリットとしては、マージ作業の手間がかかる場合があるのと、マージさせたときにソースの競合が発生するとその解決に時間がかかるという点でしょう。
Mercurialの概要
Mercurial公式サイト：https://www.mercurial-scm.org/
Mercurialはクロスプラットフォーム型の分散バージョン管理システムです。クロスプラットフォームとは、例えばWindowsとMac OSのように違うOSという異なるプラットフォームであっても同じ仕様で動作するソフトウェアのことを指します。
MercurialもGitと同時期に開発がスタートしています。
特徴としては同じ分散バージョン管理システムであるGitと似ています。
Mercurialは「履歴は永久的で神聖である」という哲学を持っていて、履歴を操作するコマンドとしては1種類しかありません。その一方で、Gitは履歴を操作できる範囲が広いという違いがあります。
Subversionの概要
Subversion公式サイト：https://subversion.apache.org/
SubversionはGit/Mercurialと違い、集中バージョン管理システムに分類されます。リポジトリが１つだけあり、それに対して複数の開発者がアクセスします。
コミットするたびに新しいリビジョン番号(バージョン)が振られるため、直感的にバージョン管理しやすい一方、複数で１つのリポジトリにアクセスするため、競合が発生しやすいというデメリットもあります。誰かがソースコードをチェックアウトしているときは他のメンバーは編集することができません。
Subversionのメリットとしては導入コストの低さでしょう。開発プロジェクトメンバーの中でもスキルの格差が大きいことはよくあります。スキル的にも優れていてGit/Mercurialのような分散バージョン管理システムに精通しているメンバーだけがいるとは限りません。そのような場合、直感的に操作しやすいのは集中バージョン管理システムであるSubversionでしょう。分散バージョン管理システムの理解が難しいメンバーに教育するコストも必要ありません。
デメリットとしては、Subversionではコミットするところが、ただ1つだけある中央のリポジトリであるため、動かないコードをコミットすることが許されません。1人のミスが開発メンバー全員に影響します。実際の開発現場でも、誰かがコミットしたソースコードが原因でソフトウェアが動作しなくなり、リリース時に問題となるケースもありました。ローカルにコミットできる分散バージョン管理システムではこの問題は発生しません。
まとめ
ここまで、Git, Mercurial, Subversionという3つのバージョン管理システムをご紹介してきました。
最後に3つそれぞれの特徴を表にまとめてみました。それぞれの特徴を把握しつつ、現場に最適なものを選択しましょう。
| Git | Mercurial | Subversion | |
|---|---|---|---|
| タイプ | 分散型 | 分散型 | 集中型 |
| メリット | ブランチを活用できる | ブランチを活用できる | 導入コストの低さ |
| デメリット | マージ作業にコストがかかる | マージ作業にコストがかかる | ローカルにコミットできないため、影響範囲が広い |
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
