【バージョン管理ツール入門第2回】

2026年3月10日

バージョン管理ツール入門：第1回｜第2回（今ここ）｜第3回｜第4回｜第5回｜第6回｜第7回｜第8回｜第9回｜[目次へ]

1. ファイルコピー管理の限界
- 1.1. 前回の振り返り
2. よくあるファイル管理
3. どれが最新かわからない
4. 変更内容が分からない
5. バグがどこで入ったか分からない
6. チーム開発ができない
7. USBバックアップでは足りない理由
8. 実際に起きた失敗例
9. バージョン管理システムの登場

ファイルコピー管理の限界

前回の振り返り

前回は、プログラムを書いていると「昨日のコードに戻したい」という問題が必ず発生することを説明しました。

そこで多くの人が最初に行うのが、ファイルコピーによる管理です。プログラミング学習者や、Gitをまだ使っていないエンジニアにも、この方法を使っている人が少なくありません。

よくあるファイル管理

例えば次のような形です。

Program.cs
Program_v2.cs
Program_fix.cs
Program_final.cs
Program_final2.cs
Program_really_final.cs

最初はこれでも問題ありません。「壊れても前のファイルが残っているから大丈夫」と思うからです。しかし、開発が進むにつれて問題が起きます。

どれが最新かわからない

複数のファイルがあると、どれが一番新しいのか分からなくなります。

よくあるのが「どれを開けばいいですか？」という質問や迷いです。Program_final2.cs と Program_really_final.cs のどちらが新しいのか、ファイル名だけでは判断できません。日付を見ても、昨日保存したつもりが別のファイルを編集していた、ということもあります。

変更内容が分からない

2つのファイルを見ても

どこを変更したのか
何が違うのか

がすぐには分かりません。

例えば Program.cs と Program_final.cs を並べて開いても、数百行あるコードのどこが変わったのか、目で追うのは大変です。特に条件式の >= を = に変えてしまったような小さなミスは、見つけるのに時間がかかります。

バグがどこで入ったか分からない

「昨日まで動いていたのに、今日動かなくなった」

このとき、どのファイルのどの変更が原因か特定するのが難しくなります。Program_v2.cs で動いていたなら、Program_fix.cs の「修正」で何か壊した可能性があります。しかし、2つのファイルを比較して原因を突き止めるのは、初心者には負担が大きい作業です。

チーム開発ができない

もし2人で同じファイルを編集したらどうなるでしょうか。

Aさんが画面のコードを変更
Bさんが計算処理のコードを変更

ファイルコピー管理では、どちらかが先に保存した方が、もう一方の変更を上書きしてしまいます。USBメモリでファイルをやり取りする場合も、同じ問題が起きます。どちらを残すのか、手動で統合する必要があり、ミスが発生しやすくなります。

USBバックアップでは足りない理由

「USBにコピーしておけば大丈夫」と思う人もいるかもしれません。バックアップはPCが壊れたときの復旧には役立ちます。

しかし、どのコピーが最新か、いつ何を変えたかは分かりません。USBに backup_3月1日 と backup_3月5日 のフォルダがあっても、その間の変更内容を追うことはできません。複数人で共有する場合も、誰の変更を採用するか判断できません。

バージョン管理は、単なるコピーとは違う仕組みです。履歴として「いつ・誰が・何を変更したか」が残るため、過去の状態に戻したり、変更内容を確認したりできます。

実際に起きた失敗例

よくある失敗例を紹介します。

ある学習者は、課題提出の直前に Program_final.cs を編集していました。しかし実際に提出したのは、古い Program.cs を ZIP にしたものでした。本人は「final の方が新しい」と思っていましたが、フォルダ内の並び順で Program.cs を選んでしまったのです。

業務では、新人エンジニアが「最新版」を渡したつもりが古いファイルを渡してしまい、チームが混乱した例もあります。このように、ファイルが増えるほど「どれを使うか」の判断が難しくなります。