こんにちは。
文系卒×現役SIerの AiCas（アイキャス） です。
エンジニアとして現場に出たばかりの頃、
私は サブバージョン（SVN） がまったく理解できませんでした。
- コミット？
- チェックアウト？
- trunk？
正直、何を言っているのか分からなかったし、
「そもそも、なんでこれ必要なの？」 と思っていました。
この記事では、
文系卒エンジニアだった僕が SVNで本当につまづいたポイントと、
後から分かった ソース管理の意味を、失敗体験ベースで整理します。
SVNの意味と役割が分かれば、
「いつ」「誰が」「どこを」変えたかが分かるようになり、
チーム開発で迷わなくなります。
SVNが分からなかった原因は、
- 操作を覚えていなかったから
- 用語を暗記していなかったから
ではなく、
「ソース管理が何のために存在するのか」を理解していませんでした。
1. SVNが分からなかった原因①｜そもそも「ソース管理をする意味」が分からなかった
新人時代の僕は、本気でこう考えていました。
担当ごとに修正するソースは決まっているよ！
同じファイルを複数人で触ることはないからソース管理いらなくない？
実際の現場でも、
- 画面担当
- ロジック担当
- バッチ担当
のように役割が分かれていたため、
「競合することはないはず」 と思い込んでいました。
この時点で、
SVNの役割を 完全に誤解 していました。
2. SVNが分からなかった原因②｜「NASに置けばいいじゃん」と本気で思っていた
次に出てきたのが、この発想です。
最新のソースが欲しいなら、
NASや共有サーバに置いておいて、各自で更新すればいいのでは？
今なら危険すぎる考えだと分かりますが、
当時は 何が問題なのか分かりません でした。
- 誰が
- いつ
- どこを
- なぜ修正したか
という履歴の重要性を、理解していなかったからです。
SVNは単なる「保存場所」ではなく、
変更履歴と責任を管理する仕組み。
この前提を知らなかった僕には
SVNはただの「面倒なツール」にしか見えていません。
3. SVNが分からなかった原因③｜用語が意味不明すぎて、完全に思考停止した
さらに追い打ちをかけたのが、用語の壁です。
3.1 コミット
コミット？
…ライザップかな？
3.2 チェックアウト
ソースのエラーをチェックすること？
3.3 trunk
src と何が違うの？
今見ると笑えますが、
当時は 全部同じくらい分からなかった です。
用語を知らないのではなく、
何を指している言葉なのか分からなかった。
4. 後から分かったSVNの正しい整理
しばらく経って、ようやく理解できた整理がこれです。
4.1 SVNは「ソースの履歴管理装置」
- 誰が
- いつ
- どこを
- どう変えたか
を 全部残す仕組み。
4.2 用語を一気に整理するとこうなる
チェックアウト
→ 共有リポジトリから「自分の作業用コピー」を取得すること
コミット
→ 自分の修正内容を、履歴として共有リポジトリに反映すること
trunk
→ メインとなる開発ライン（最新版が集まる場所）
SVNは「みんなで安全に作業するための保険」 でした。
5. SVNの本当の価値は「事故が起きたとき」に分かる
新人時代の僕には、これが分かっていませんでした。
- 間違って消した
- 動いていたものを壊した
- どこで壊れたか分からない
こういう 事故が起きたとき に、
- すぐ戻せる
- 原因を追える
- 責任範囲が分かる
それが SVN の本当の価値です。
6. 今なら後輩にこう説明する
もし今、当時の自分に説明するなら、こう言います。
- SVNは「共有フォルダ」じゃない
- SVNは「履歴付きの便利ツール」
- コミットは「記録を残す行為」
- チェックアウトは「作業場を作ること」
これを最初に知っていれば、
あんなに混乱しなかったと思います。
7. まとめ｜SVNでつまづくのは当たり前
SVNが分からなかった新人時代の自分は、
- センスがなかった
- 向いていなかった
わけではありません。
前提知識を知らなかっただけです。
このブログでは、
こうした 実務での思考のズレ を、
後から言語化していきます。
同じところで立ち止まっている人の
「地図」 になれば嬉しいです。
コメント