【バージョン管理ツール入門 第1回】
バージョン管理ツール入門：第1回（今ここ）｜第2回｜第3回｜第4回｜第5回｜第6回｜第7回｜第8回｜第9回｜[目次へ]
プログラムを書く人が最初にぶつかる問題「昨日のコードに戻したい」
プログラムを書いていると必ず起こること
プログラムを書いていると、ほぼ必ず次のような経験をします。
- 昨日まで動いていたコードが動かなくなった
- どこを変更したのか思い出せない
- 元の状態に戻したい
これは特別なことではありません。むしろソフトウェア開発では日常的に起きる問題です。
プログラミングを教える場面や、コードを書く現場でも、次のような声をよく聞きます。
「さっきまで動いていたのに、急に動かなくなりました」
原因を調べると、多くの場合は次のどちらかです。
- 条件式を変更した
- ループの条件を変更した
つまり、どこかの変更が原因なのです。しかし、その変更がいつ・どこで行われたのかを追うことができません。
ここで必要になるのが、バージョン管理という考え方です。この問題は、プログラミングを始めた人なら誰でも経験することです。
よくある管理方法
プログラミングを始めたばかりの頃、多くの人は次のようにファイルを管理します。
Program.cs
Program_final.cs
Program_final2.cs
Program_final3.cs
Program_realfinal.csこの方法は、一見すると安全そうに見えます。「壊れても前のファイルが残っているから大丈夫」と思うからです。
しかし時間が経つと、次の問題が起きます。
- どれが最新かわからない
- どこを変更したのかわからない
- バグがどこで入ったのかわからない
つまり履歴を管理できていないのです。
ソフトウェア開発は「修正」の連続
ソフトウェア開発は「作る」よりも「修正する」時間の方が圧倒的に長いと言われています。
例えば、次のような作業です。
- 新しい機能を追加する
- バグを修正する
- 仕様変更に対応する
このような変更は、プロジェクトが続く限り何百回、何千回と発生します。
そのため、ソフトウェア開発では変更履歴を管理する仕組みが必要になります。このような仕組みは「バージョン管理」と呼ばれ、専用のツールがあります。
しかし多くの人は最初、ファイルをコピーして管理してしまいます。一見すると安全そうですが、実は限界があります。
次回
次回は「ファイルコピー管理の限界」について詳しく説明します。なぜその方法ではうまくいかないのか、そしてバージョン管理システムがどのような解決策を提供するのか、理解できるようになります。