Git は Subversion の何を解決するのか
この記事は上司の発言にモヤッとした気持ちを発散するため、そして Git のメリットを社内に説明するためのポエムです。
今時 Subversion なんか使ったこともないという方も多いと思いますが、世の中にはこんな悩みを抱えているエンジニアがいるんだなと温かい目で見守っててください。
とある飲み会にて
上司: Git とか Slack とか新しいツールが便利って言うけど、それってただ新しいものを使いたいだけじゃないの?
僕: まあそういう側面も否定はできませんが、、、
上司: 別に今運用で困ってるわけでもないのにわざわざ新しいものを試す理由がないでしょ、実際に使いにくいって声も多いし。
僕: それはただ慣れてないからってだけじゃないですか?
上司: 結局それぞれが使い慣れているものを使うのが一番いいんだよ。それに Git よりも良いツールが出たらそっちを使いたいって言い出すんでしょ?
僕: いいものが出ればそれに変えたいとは思いますけど。
上司: ほらね、そうやって新しいもの追いかけてばかりじゃきりが無いでしょ。
僕: ぐぬぬ。。。
Git の良さを理解してもらいたい
私の会社では Git と Subversion の両方が使われています。
昔からあるプロジェクトは Subversion で管理されており、最近のプロジェクトでは外注さんとやり取りする関係で Git も使い始めたという感じです。
数年前に私が入社した時点ですでにこのような形で運用されていました。
Subversion 面倒だなと思いつつも、慣れてきたら勝手に Git へ移行していくだろうと楽観視していました。
ところが先日、先の会話のように社内では Git 反対派が一定数いることが判明しました。
このままではいかん、Git の良さをなんとか理解してもらわなければ。
そう思って、今回改めて Git と Subversion の違いを自分の言葉で言語化してみました。
補足: 古いツールを使い続けるリスク
本題とはそれるのですが、上司の｢新しいものを使いたいだけ｣という言葉に同意できる部分もあるので、一旦そこに対する自分の考えをまとめます。
古いから変えたいと思ってる側面があるのも事実ですし、今大きなトラブルなく回っていることもそのとおりだと思います。
ただより良いものがあるのにリスクを嫌って移行しないのは、単なる怠慢だと思います。
もし仮に Git を使うと生産性が絶対に向上するとしたら、Git を使う競合他社に対して我々の競争優位性が低いということになります。
つまり慣れた環境を維持することでリスクを避けたつもりが、逆にビジネスというより大きな環境でのリスクとなっているということです。
何でもかんでも新しいものにすべきとは思いませんが、逆に現状維持を理由に古い仕組みのままでいることはビジネス上のリスクである、というのが私の考えです。
Git と Subversion の最大の違いは管理するスコープの大きさ
個人的な考えですが、Git と Subversion は管理する対象が大きく違っていると思います。
ざっくりと説明するなら
- Subversion はソースコードの最終成果物を管理
- Git はソースコードに対する個人の作業内容を管理
といったイメージです。
そして管理する対象が変わったことで Subversion では難しい以下のようなことが容易にできるようになりました。
- 手戻りも含めた試行錯誤の実践
- 関連する作業だけをひとまとめに管理
- 他のメンバーに影響を与えずに作業を進める
これにより Subversion では難しかった、変化に対する柔軟性を Git は実現しています。
もう少し具体的に説明してみます。
分散型管理システムに変わった理由は作業を管理しやすくするため
Git の大きな違いとしてよく説明されるのが分散型バージョン管理システムだという点です。
これは事実なのですが、初めて聞くと｢だから何?｣と感じるでしょう。(私もそうでした)
そこでまずは、分散型になったことによって何ができるようになったのか考えてみます。
Subversion はチームの最終成果物を管理
集中型管理システムの Subversion ではコミットした瞬間にサーバーへ記録されてしまいます。
これにより、暗黙的に一連の作業が完了した段階でのコミットが求められます。
例えば、機能を実装中でテストが完了してないコミットをしたとします。
もしそこに致命的なバグが含まれており、作業中の他メンバーの環境でそれが再現したらどうなるでしょう。
バグの内容を時間をかけて調査したり、開発中だと気づかずに上司へエスカレーションしてしまうかもしれません。
このような事態を避けるために、作業が中途半端な状態でコミットするのはためらうようになります。
後述するブランチの切りづらさもこの傾向を促進します。
Subversion ではコミットした結果は完成している状態が大前提です。
コードへの最終的な変更だけを管理し、作業の途中経過を管理することは想定されていません。
このことから Subversion はチームの成果物を管理するのに適したツールといえるでしょう。
Git は個人ごとの作業・進捗を管理
Git が分散型になったことによる一番の変化は、コミットをサーバーではなくローカルで管理できるようになった点です。
これにより、作業が中途半端な状態でもチェックポイント的に作業履歴を残していくことができるようになりました。
なぜならコミットしてもサーバーに保存されないため、システムが機能してなくても誰も困らないからです。
また、ローカルでのみ管理しているコミットは後戻りしたり消したりすることが簡単にできます。[1]
そしてすべての作業が完了した段階で、途中経過をすべてひとまとめのコミットとして作り直すこともできます。
サーバーに記録しなければ誰も途中経過を知らないのですから、コミットを消そうが作り直そうが何も影響はありません。
ローカルコミットで自由に作業できるイメージ図
このように Git を使うことで細かく作業履歴を残しつつ試行錯誤を繰り返し、ときにはコミットを後戻りしつつ、効率的に作業を進めることができます。
つまり Git はコードそのものではなく、作業者がコードに対して何をしたのかという点を管理しているのです。
Git のブランチは作りやすく取り込みやすい
Git と Subversion の両方を使っていて一番大きな違いだと感じたのは、ブランチの取り扱いです。
Git を先に使い始めた私は Subversion でのブランチの扱い方になれるのに苦労しました。
そして社内の人たちも Git と Subversion のブランチの違いが腹落ちしていないように見受けられます。
このブランチの違いを理解することが Git の良さを理解する大きな一歩になるはずです。
Subversion はブランチを長期的に管理する
Subversion でブランチを切るという行為にはそれなりの覚悟が必要です。
特に弊社では、ブランチがリリース単位として扱われるケースが多いので、雑にブランチを切ることがためらわれます。
そしてブランチを切りたくない一番の理由はマージの大変さです。
Subversion のブランチ管理の大変さをまとめると以下のようになります。
- ブランチ先とブランチ元が完全に別物として扱われる
- マージするコミットを手動で選択
- マージコミットだけ作られてブランチのコミットログがマージされない
これらの問題点によりマージコストがとても重く、小さい変更ほどブランチを切るのが億劫になりました。
これらのことから Subversion のブランチは一時的なものではなく、長期的に管理するものだと捉えることができます。
Subversion におけるブランチは、ソースコードの別バージョンとして管理することが前提となっている印象です。
このことからも Subversion はあくまでソースコードの最終成果物を管理していると言えるでしょう。
Git のブランチは使い捨てる前提
一方 Git ではブランチを切るのがとても簡単。
むしろ main ブランチでは作業せずにとりあえずブランチを切ることが推奨されます。
そしてマージがとても簡単で、ブランチを指定すれば差分を自動でマージしてくれます。[2]
そのため一時的に作業用ブランチで作業してから main ブランチにマージ、作業用ブランチはその都度削除する、という流れで作業ができます。
このようにブランチを一時的な作業スペースとして扱うことで、関連する作業の一連の記録をブランチ単位で閉じ込める事ができるのです。
またブランチをマージすると、ブランチ上のコミットログをそのまま反映することができます。
そのため、ブランチ先でどのような作業を行ったのかが把握しやすくなります。
ブランチを使った Git の典型的なワークフロー
このブランチを一時的な作業場として使い捨てる流れをより使いやすくしたものが GitHub などで使われる Pull Request です。
これにより Subversion では難しかった関連する一連の作業をひとまとめにチェックすることが容易になりました。
Git を使うことで、ソースコードだけでなく作業の進捗状況も管理しやすくなるのです。
Git と Subversion の違いを理解して使いこなそう
簡単にですが Git と Subversion の違いから Git が解決した Subversion の課題点について説明してみました。
Git を使うことで、Subversion では難しかった2つの課題を解決することができます。
- 周りに影響なく個人の作業を管理
- 関連する作業をブランチ単位でわかりやすく管理
これらに共通するのは、ソースコードだけでなく作業者が何をしたのかを管理しやすくなったという点です。
Git は複雑で変化が多い作業を行うエンジニアにとって、非常に使いやすいツールと言えるでしょう。
また Git と Subversion はそもそも管理する対象が異なっているので、同じ感覚で使おうとすると使いこなすことは難しいでしょう。
Git はソースコードではなく作業者という人に焦点を当てたツールだと思ってます。
そのため Subversion と比べると、我々がこうしたいと思ったことが格段に実現しやすいです。
Git を使いこなしてより快適なエンジニアライフを送りましょう。
それでは。
Discussion