ドキュメント管理はSubversion、ソースコード管理はGit

投稿日：
「リモートワークでもバージョン管理システムを使うと幸せになれるよ」と教えるときに調査したときの覚書。

結論からいうと、IT技術職のソースコード管理はGitが便利。
それ以外のデザイナーや営業などのドキュメント管理はSubversionが便利。

以下特徴など

１．Subversion

特徴
  • 集中型のバージョン管理システム。
    → 集中管理サーバーが壊れれば変更履歴ログもなくなる（今やサーバー側が多重化されているのでこの心配はほとんどない）
    → ユーザーはファイルの最新版のみ持っている（Gitに比べるとディスク容量が少なくて済む）
  • 2000年初版。
  • ネットワークストレージ（NAS）をクラウド型にしたイメージ。
    → 誰でも直感的に使える。
  • TortoiseSVNで技術職じゃなくても使ってくれる。
  • ファイルのロック機能で、自分が編集していることを周知することができる。
  • フォルダごとにアクセス権限を設定できる。

使ってみての感想
  • 昔MicrosoftのSourceSafeを使っていた人はだいたいこれに移行。
  • Subversionのマージ機能で地獄を見た人多数。
  • 運用ルールを定めればソースコード管理も問題ない。
  • お堅い担当者が自分たちでガチガチに権限設定して集中管理したいという場合はSubversionから離れられない。


２．Git

特徴
  • 分散型のバージョン管理システム。
    → 各ユーザーは全ての変更履歴ログを持っている（多くのディスク容量が必要）。
    → どこか１つでも生き残っていれば変更履歴まで復元できる。
  • 2005年初版。
  • Linuxカーネルのソースコード管理のために開発された。
  • （テキストの）マージ機能がとても優秀で動作が軽い。
  • Gitの考え方を理解するのに勉強が必要
    → Subversionと比較して学習コストが高い
    → GitHubがGitの機能を見やすく管理できるインターフェイスを提供して一気に広まった。
  • GitHubやGitLabでプライベートリポジトリが簡単無料で作れる。
  • GitHubではSubversionも使える（参考：GitHub で Subversion を使う - GitHub ヘルプ）

使ってみての感想
  • 新機能を開発するときにブランチ作って、機能が完成したらマージすることが安心してできる。
    → Subversionでこれを行うと地獄をみる（運用ルールで回避可能）
  • 今やオープンソースプロジェクトはGitHubで管理するのが当たり前。
  • ファイル名の変更や移動をGitが自動判断してくれるので開発に集中できる。
    → Subversionだとファイル名の変更や移動は大きなイベントなので、最初ファイル名やフォルダ構成を決めるのに結構悩む。


私の感覚としては、ソースコードが外部に流出したとしても痛くはない。大事なのはデータ。
だからGitHubやGitLabなどの外部サービスで管理するのは問題ない。
だけど機密保持情報が多分に含まれたドキュメントは自サーバー＋Subversionで安心安全に管理するべきだと思う。