こんにちは！皆さんはソースコード管理にどんなツールを使っていますか？
ソースコード管理と言えば、現在ではGitが主流となっていると思います。私は普段はGitを使ったプロジェクトに携わっていますが、久しぶりにSubVersion（SVN）を使う機会がありましたので、KENTEMのソースコード管理の歴史を振り返ってみました。

黎明期：ファイルサーバー一括管理時代

初期の頃は、ソースコードのバージョン管理ツールなどは何もありませんでした。とは言え、チームで開発をしているので、全員で同じソースコードを編集する必要があります。当時は、共通で使用するコードはサーバー上に置き、それを複数人で修正していました。

バージョン管理	フォルダーをバージョンごとにコピー
競合管理	声掛けで調整
履歴管理	ソースコードの冒頭や末尾にバージョンや修正内容をコメントコード本文より長い履歴になることも！
ビルド	プロジェクトリーダーのマシンで実行

とってもレガシー！
当時は開発部の規模が小さく、１部屋にメンバーが全員そろっていたので、共通コードを変更する際は
「〇〇のコード保存します！」
と声を掛けていました。新人の頃は大きな声で宣言するのが恥ずかしい反面、共通コードに手を入れる誇らしさも感じていました。
修正タイミングが被った場合、当然ながら自力でマージする必要がありました。
また、ファイルの正しさの保証するために、ソースコードのコメントに記載した日付と、ファイルの更新日がずれないように気を配る必要もありました。何の変更もしていないのに不用意に保存してしまうと、バックアップを掘り出してどこが変わったか確認する羽目になります。

拠点が複数に分かれ、リモートメンバーも存在する現在では、考えられませんね＾＾

転換期：SubVersion時代

さて、開発もメンバーが増え、大人数で１つの製品を作ろうとすると、どうしてもソースコード管理に煩雑さが増してきました。また、誰かが入れた修正で、以前は動いていたコードが動かなくなるなどの問題も発生し、開発工数が圧迫されることが多くなりました。
これらの課題を解決するために、バージョン管理ツールとしてSubVersion（SVN）が導入されました。

同時に、コードレビューの文化も取り入れられました。 製品に対するコード修正はすべてレビューを通してからコミットする というルールが設けられました。それまでは、一部しかソースコードレビューは行っていなかったため、全レビューすることで実装速度が落ちると反発もありました。結果的に、レビューすることで実装段階でのミスを減らすことができ、テストフェーズでの不具合が減少しました。レビューに時間がかかっても、最終的に品質アップにつながると啓蒙活動を行ってくれた先人達に感謝です。

バージョン管理	SVN
レビュー	レビュイーがレビュアーに声をかけて自席で実施
履歴管理	コミットコメント
ビルド	社内のJenkinsサーバーで実行

SVNの導入により、ブランチを使った並行作業が可能になり、ソースコードの変更履歴管理がより効率的になりました。

発展期：Git時代

レビュー文化が広まってきた頃、SVNと違うバージョン管理ツールを使ってみようと試みるメンバーが出てきました。
Gitの導入です。
Gitの利点として、プルリクエストを使ったレビューが挙げられます。これにより、以下のメリットが得られました。

変更点一覧がWeb上でわかりやすい
レビューコメントを残せるため、修正漏れを防げる
レビュアーとレビュイーの時間を合わせる必要がない
修正分は一度コミットされているため、並行作業がしやすい

さらに、GitとSubVersion（SVN）の違いも重要です。 Gitはローカル管理型であり、各開発メンバーが自分のローカルリポジトリを持ちます。対して、SVNはサーバー集中管理型であり、すべての変更がサーバーに集約されます。お試しでブランチを作りたい場合も、リモート上に作ることになります。

個人的には、このローカルブランチ管理が便利で、個人の並行作業がやりやすくなりました。

バージョン管理	Git
レビュー	プルリクエスト
履歴管理	コミットコメント
ビルド	社内JenkinsサーバーからGitHubへ

Gitは便利ですが、上記のような変遷を経てきたため、KENTEM社内のソースコード管理がすべてGitに移行したわけではありません。また、中央集権型のSubVersionの方がシンプルで導入しやすいため、開発外の部署とのやり取りには、SubVersionを使用しているケースもあります。
GitとSubVersionそれぞれの特徴をしっかり把握して、間違いのないように使っていきたいですね。