Webなどの仕事をしていれば今やGitやSVN(Subversion)とかを当たり前のように使っていると思ってましたが、実はそうではないところもまだまだあるということを耳にします。
理由は様々あると思いますが、よく聞くのがメリットを見いだせないとか、1人で作業する分には不要だとかを聞くことがあります。

今回は仕事をする上で、1人だろうと複数人だろうと、プログラムだろうと単なる文章においてもGitなどのVCS(Version Control System)を使ったほうがいいよというメリットを紹介します。
以降の文脈に置いてはGitやSVNなどのリビジョン管理システムを総称してVCSと表記します。

バックアップを取る必要がない

エクセルとかでやり取りをするときを思い出してください。
ファイル名に日付を入れて管理したりすることがありますよね。
VCSを使うとコミットされた履歴だけでなく、ファイルごとに履歴を確認することができるのでわざわざバックアップファイルを作る必要がないのです。

更新履歴が確認できる

VCSはコミットごとにリビジョンが作成されるため、過去にどのような変更を加えたのかがわかるようになっています。
振り返りを行なったり過去にどういう経緯で、どこを変更したなどの情報が詰まっている貴重な財産になります。

そのため、コミットを行うタイミングやコミットメッセージはより適切に行う必要があります。
ただし、コミットメッセージを「更新した」とかだけでは情報が雑なので気をつけましょう。
コミットメッセージはConventional Commitsという思想がおすすめです。

差分ファイル自体や差分ファイルのリストを取得できる

Webサイトなどを更新する際によくあるパターンとして、変更したファイルのみ本番にアップロードしたいということがあります。
VCSを使っていないとどこかにメモをとり続ける必要がありますが、VCSを使っているとコマンドを叩くだけで生成ができます。

例えば、Gitの場合は下記のコマンドを利用することでリストを生成することができます。

# ファイルの変更リスト(新規、削除含む)をダウンロードディレクトリにテキストファイルで保存
$ git diff --name-status <older revision> <newer revision> > ~/Downloads/modified.txt

# 差分ファイル(新規、変更)の実態ファイルをダウンロードディレクトリにzipで保存 (削除ファイルは無視)
$ git archive --format=zip HEAD^ `eval git diff --diff-filter=AMCR --name-only <older revision> <newer revision>` -o ~/Downloads/file.zip

実際にファイルリストを出力した場合(A=新規, M=更新, D=削除)。

A   foo/bar/index.css
M   foo/bar/index.html
D   foo/bar/ide.png

リリース日が違うときや機能を段階的に対応したりすることが容易

VCSというか特にGitはブランチがあるので別々のリリースや機能ごとに集中したい時などにも対応ができます。
ブランチを作成することで1ページ内でAセクション追加を明日、Bセクション追加を明後日といったときにブランチを分けることで変更のみに集中ができます。
最終的に main(master) ブランチなどにマージをすれば差分を反映することもできます(同一行を変更していたらコンフリクトが起きますが)。

変更中のファイルを一時退避させる

作業をしているとどうしても緊急対応しなければいけないときもあります。
そんな時、作業中のファイルをどうするか？
特にGitならStash機能を使うことで一時的に変更状態の変更箇所を別で保管して変更前の状態に戻せます。

緊急対応が終わったら一時退避させた変更分を復活させて作業を再開することができます。
この機能を使うことで、緊急対応で必要な変更のみに対応できるため、それまでやっていた変更分のことを気にする必要がなくなります。

わかりやすい緊急対応を例に挙げましたが、それ以外にも今対応すべき箇所以外の行をリファクタリングしたいといった時にも、リファクタイングした行のみを一時退避させるということもできます。

巻き戻し(ロールバック)も可能

リリースしたのはいいけど、致命的なバグが存在したときなどは以前の状態に戻したいということがあります。
サーバーにバックアップを取っていればそれを使えばいいですが、そうでない場合でもVCSで管理していればリリース前の本番リビジョンに戻ってそのファイルを再リリースすることもできます。
履歴を蓄積しているからこそできます。

この手の巻き戻し(ロールバック)をする場合は、開発中は develop などのブランチで作業をして、リリースのときに main(master) ブランチにマージをすると巻き戻すタイミングが分かります。
バージョンタグを付けておくとなお良しです。

この手法はGitflowやGitHub Flowと呼ばれ、プロジェクトの性質によって使い分けることが多いです。

巻き戻しは、リリース後の対応だけでなく開発中でも「やっぱり前のに戻して」とかも経験ありませんか？
こういうときにもコミットを取り消したり、過去のコミットを再適用したりするときにも使えます。

今まで案件でVCSを使ったことがなかった、あるいは案件ではあるけど1人のときには使ったことがなかったといったといったことがあればこれを機会に常に使うようにしてみると良いです。
複数人だろうと1人だろうとクライアントから何を要求されるかわからないので、素早く対応できる状況を作るということは大事です。
また、個人的にサイトやサービスを作っていたとしても履歴を残すことでナレッジとして蓄積することができます。

WebなどのITだけでなく、社内文書や小説などの文字情報だけのときにもVCSを使うことで、いつ何を変更したのかという履歴を振り返ったりすることができます。

いつどこで何を変更したのかなどを常に覚えておける訳はないので、こういったものを使うことでいざ過去が必要なときに役立つので、まだ利用していない人は是非利用してください。

今回はプログラムなどのコードを管理するVCSの話をしましたが、サービスでも同じで履歴が蓄積できるというのはそれだけ選択肢が増えます。
サービスだとGoogle SpreadsheetなどのGoogleのドキュメント類やWordPress、Notionなどでも同じように履歴が残せるサービスやツールは、間違っても簡単に取り返せるという安心感があります。

安心感って何をするにしても心理的ハードルが下がるので大事です。