gitとsubversionの違いについて良く聞かれるので、記事にしてみました。
【git・subversionとは？】
gitもsubversionも共にバージョン管理システムであり、古典的なバージョン管理システムであるCVSからの流れを汲んでいます。
バージョン管理システムとは、ソースコード等のファイルを管理するシステムであり、過去のバージョンを保持することができるため、障害や要望が発生した時にある時点のバージョンまで遡ることが容易になります。
（バージョン管理システムを使っていれば過去のバージョンを指定して落としてくるだけで良いですが、使っていないと手動で過去バージョンのファイルをかき集めたり復元したりという作業が発生します）
gitの方が後発ですが、現在はgitの方がメジャーです（少なくとも国際的には）。
【gitとsubversionの違い】
一言で言うと、subversionは集中型バージョン管理システム、gitは分散型バージョン管理システムという違いがあります。
集中型と分散型の違いについては、下記図に表しました。
集中型管理システムでは、リポジトリ（ファイルのバージョン管理を行う書庫）はリモート環境にのみ存在します。
メンバーはリモート環境のリポジトリにアクセスし、各メンバーのローカル環境にあるファイルをコミット（新バージョンとしてファイルを保存）したり、ローカル環境へチェックアウト（特定のバージョンのファイルを取得）したりします。
一方、分散型管理システムでは、リポジトリはリモート環境のみでなく、各メンバーのローカル環境にも存在します。
メンバーは自分のローカル環境のリポジトリに対し、コミットやチェックアウトを行います。
ローカル環境でコミットしたファイルについては、適切なタイミング（テストが完了したタイミング、リリース準備を行うタイミング等）でプッシュを行い、リモート環境のリポジトリへコミットを反映させます。
また、ローカル環境のリポジトリを作る際は、リモート環境のリポジトリから特定のバージョンの情報をプルで取得します。
【分散型管理システムの利点】
利点はいくつか挙げられますが、一番本質的な利点は自分のコミットが他のメンバーへ影響を与えずに済むという点です。
集中型管理システムの場合は、コミットしたファイルは即座に他のメンバーも取得可能となるため、仮にバグを取り除き切れていないソースコード等をコミットしてしまうと他のメンバーに迷惑をかけてしまいます。
しかし、分散型管理システムであれば、自分のリポジトリでチェックしてからリモート環境のリポジトリへ反映させることができるので、他のメンバーへ迷惑をかけずに作業を進めることができ、生産性が向上します。
他には、「分散型管理システムであればローカル環境のリポジトリがバックアップとなるため障害耐性が向上する」等の利点を挙げる文献もありますが、個人的には本質的な利点だと思っていません。
（例えばバックアップの例なら、集中型管理システムでも定期的にバックアップを取得する運用体制とすれば障害耐性を向上させられます）
【gitにおけるブランチの使い方】
gitではブランチを使用することができ、コミットを複数に枝分かれさせることができますが、自分のコミットが他のメンバーへ影響を与えないという利点は、ブランチ機能と親和性があります。
gitの場合は、「機能毎に担当者を決める→各々の担当者がブランチを切る→自分が開発した機能を自分のリポジトリへコミットする→自分の環境で機能の検証を行う→検証済みのコミットをリモート環境のリポジトリへプッシュし、枝分かれしたコミットをマージする」という開発体制を取ることができます。
このように、担当者毎・機能毎でブランチを切ることができるため、機能毎にプッシュ可否を判定する、ある機能だけバージョンを戻す、といった柔軟な運用が可能になります。
なお、subversionにもブランチの機能はあるのですが、各担当者が思い思いにブランチを切るという使い方はできないので、バージョン毎（マスターバージョンとβバージョン等）に複数機能をまとめてブランチを切る、という使い方になります。
システム開発の仕事をする上では、単にプログラムを作れるだけでなく、開発環境についても理解する必要があります。
プログラミング研修を終えていきなりバージョン管理システムに触れると色々疑問に思うことが出てくると思いますので、今回の記事が助けになれば幸いです。
これからも、開発者のためになる記事を書いていきたいと思います！