【知らないと損】ソフトウェア技術者がGitを使用すべき理由4選【徹底的な差分管理】
はじめに
どうも、私立YouTube高専校長です。 本日は、「全ソフト開発者に告ぐ。今すぐ使え！Git」ということで、Gitがソフトウェア技術者にとって、 いかに素晴らしい開発ツールであるかを解説したいと思います。 別に、Gitじゃなくて、Subversionでもなんでもいいから、徹底的に差分管理しようぜと、そういう話です。
ソフトウェア不具合は、ソースコードの差分から発生します。 ソースコードを変えなければ、新しいバグは生まれません。 かといって、ソフトウェア開発をする上で、ソースコードを変える事は避けられません。
だからこそ、徹底的な差分管理を可能とするGitを導入する事で、非常に大きな恩恵が得られます。
最も単純な差分管理手法として、リリースごとにソースコードをコピペして、 フォルダ名でバージョンを管理しているという、現場も少なくないのではないでしょうか。
私の経験によると、このようなGitを使わない、管理手法は、産業機器のソフトウェアのような、 長期間保守されている小規模なソフトウェア開発に多く、非常に古いソースコードを、数人で保守・改修をメインにしているような現場が多いです。 開発が始まった当時には、Gitなんてものはなく、開発人数も少ないので、古い開発プロセスをそのまま使いまわしているというのが、実際の所だと思います。
しかし、このような大雑把な管理手法が成立するためには、特定の条件があります。 それは、大抵このような職場には、そのソースコードを数十年保守している、職人気質のおっちゃんがいて、その人の圧倒的な経験と記憶によって、開発が支えられています。 しかし、おっちゃんも人間なので、いつか辞めますし、倒れる事もあります。
そして、そういったおっちゃんがいなくなると、何が起きるかというと、ソースコードの歴史が分からなくなります。 ソースコードの歴史が分からなくなると、今見ているソースコードが一体いつ誰が何のために追加したのか分からなくなります。 これにより、後から入った人が、開発にキャッチアップする事が、非常に困難になります。 数十年保守し続けている人は例外ですが、たとえ自分が追加したものであっても、数か月もたつと、普通は忘れるものだからです。
そして、この状態でソースコードをいじるのは、非常に危険なことです。 なぜなら、チェスタトンのフェンスという有名な逸話でも知られている通り、 なぜフェンスが建てられたのか分からない状態で、フェンスをいじると、禄な事が起きません。変更の副作用がどこに現れるか分からないからです。 かといって、長期間保守されているソースコードは、これからも保守期間が長いので、おっちゃんがいなくなったからと言って、開発が止まるなんてことは許されません。
このような、不測の事態を防ぐために、コピペで差分管理している現場では、ソースコード中にコメントで変更履歴のメモが書き残されている事があります。 しかし、この管理方法だと、保守期間が延びれば伸びるほど、ソースコードがコメントだらけになって、どんどん読みづらくなるという欠点があります。 特に、いらなくなったソースコードをコメントで残されると、認知負荷が上がり、可読性が著しく落ちます。 また、コメントをつけ忘れる可能性もあります。
しかし、Gitを使うことで、このような問題を全て解決することができます。Gitを使う利点を4つ紹介しましょう。
まず、変更履歴をコミットという非常に小さな単位で残す事ができるようになり、 ソースコードの可読性を保ったまま、いつ誰が何のためにそのソースコードを追加したのかを記録することが出来るようになります。 ファイルや行単位で、差分の履歴を追う事も出来るので、参照や検索も非常にしやすいです。 コメントと違って、変更履歴を付け忘れるということも、Gitを使っている限り、絶対におきません。
また、バージョンの分岐にも非常にうまく適応しており、ディレクトリをコピペして、差分管理する運用では、どのバージョンがどのバージョンから派生しているのか、見極めるのが、不可能なので、別途エクセル等で管理する必要がありますが、Gitでは、ブランチという機能によって、どのバージョンがどのバージョンから派生しているのか、一目で分かります。
さらに、手元のソースコードを特定のバージョンに戻すことが容易で、これは、開発時において非常に強力なデバッグ方法になります。 というのも、例えばある不具合が見つかったとき、過去のバージョンに戻して、不具合が再現するかどうかを見れば、差分を追って、不具合の原因を特定できるからです。
さらに、もう1つ、Gitを使うことによって、得られる大きな利点は、同時に複数人で、ソースコードをいじる時に現れます。 例えば、Aさんが最新リリースをベースに機能Aを開発して、Bさんが最新リリースをベースに機能Bを開発したとします。 この場合、次のリリースソフトを作る場合には、ソフトウェアの差分を統合する必要があります。 コピペで差分管理する運用では、人手で統合するか、WinMergeのようなツールを使って、統合する必要があります。
一方で、Gitを使っていれば、マージという機能を使うことで、自動で差分を統合することができます。 さらに、もし、2つの差分に衝突があれば、それを検知して、次のリリースでは、どのような差分を適用するか、選択することができます。
このように、Gitを使うことで、非常に細やかな差分の管理をすることができることになり、 常に、ソースコードの差分を参照、検索しながら、開発を進める事ができます。 ここからは、実際にGitがどんなものかご紹介しましょう。
私が好んで使っている環境は、Visual Studio Codeの拡張機能で、Git GraphとGit Lensというものをつかっています。 Git自体は、CLIで操作できるソフトウェアですが、CLIは面倒です。Git Graphを使うと、バージョン履歴がグラフィカルに一目で分かるように表示されます。
Git Lensは、ファイルや行単位で履歴を遡るときに使用しています。 VS code + Git Graph + Git Lensは私にとっては、defacto stanrdの開発環境でWindowsでもLinuxでも必ず、これらをインストールして使っています。Gitは非常に有名なツールなので、これ以外にも無限に便利ツールがあるので、好みの物を使って下さい。
それでは、実際に画面を見てみましょう。
これは、私立YouTube高専のホームページの差分履歴になります。 最初にソースコードを生成したときから、コミット単位で全ての履歴が残っています。 このように、コミットごとにコメントが残っていて、そのとき、どのファイルをどのように変更したかが全て残っています。
ブランチは、2つ使い分けていて、devブランチで開発していて、本番環境はmainブランチに同期しています。 devブランチで開発が終わったら、mainブランチにマージして、差分を本番環境に適用するような、運用になっています。 ブランチの運用方法は、開発チームで合意をとって、決められた手順で運用するようにします。
ファイルや行単位の履歴は、ファイルを開いて、Git Lensの画面で、参照する事ができます。 LINE HISTORYがその行を編集したコミットを表していて、FILE HISTORYがそのファイルを編集したコミットを表しています。
ここまで、見ていただけたら、ディレクトリのコピペに比べて、Gitがいかに優れた差分管理手法であるかが、お分かり頂けたと思います。 オープンソースなので、お金はかからないし、ライセンス的にも、ソースコードの開示義務が生じるようなものでもありません。 学習コストもそれほど、高いものではありません。 ソフトウェア開発をする上で、これを活用しない手はないでしょう。
もっと具体的な使い方を知りたければ、ググれば、無限に情報が出てくるので、そちらをご参照ください。
また今回ご紹介した情報以外にも、我々は、日本の技術者の技術力向上に向けて、 5年後も10年後も役立つ、有益な技術情報を日本語で分かりやすく発信しているので、 そういった動画を見逃したくない方は、今のうちにいいねとチャンネル登録しておいて貰えればと思います。 コメントや拡散もして頂けると、非常にありがたいです。
今後は、もっと組織化して、コンピュータ科学だけでなく、 古今東西あらゆる分野のテクノロジーを解説していきたいと思うので、 是非、応援よろしくお願いします。
コメントも、非常に勉強になるので、是非よろしくお願いします。 是非一緒に、楽しいTech Lifeを過ごしましょう。
本日の動画の内容は以上になります。ここまでご視聴ありがとうございました。