はじめに
本記事は共に開発を行う同僚や友人に向けて、gitおよびgit(hub)-flowに対する理解を深めるために用意した文書を公開したものです。筆者の個人的な思想や、厳密には正しくない、適切でないとされる表現が多分に含まれます。ご留意ください。
あなたの問題を解決する具体的なコマンドや導入実例などの参考データはなく、概念について深掘りした説明をしていますので、精神的、時間的に余裕のない方は読むのをお控えください。
また、gitの仕様や活用事例に関する解説(コミットとは、プッシュとは、ブランチとは、プルリクとは、CIとは...etc)については心のこもった秀逸な記事が星の数ほどありますので、是非そちらをご覧ください。
gitとは何者なのか
プロジェクトの開発を進めるうえで、プログラムコードの修正や素材の追加などの進捗があった際、”ファイル更新に事故が起こらないように 助ける ”ことを目的としたソフトウェアである。
平成の成熟期～衰退期から令和の黎明期にかけてのプログラム開発において、最適なスキーム、選択肢であるとされている。
gitが提供する管理システムは「バージョン管理」と呼ばれ、プロジェクト全体の「今の状態」をファイル単位で監視することにより、監視を始めてからのこれまでの瞬間を年表のように遡ることができる。
これにより、「1つ前の更新状態に巻き戻す」「特定の瞬間の更新内容をつまんで取り出す」「別の可能性を入れ込んだコピープロジェクトを平行して走らせる」といった柔軟な作業体制を実現する。1
gitの何が良いとされているのか
gitの良さは**「プロジェクトの瞬間をファイル単位で管理・保存できること」**である。しかし、それ自体には実のところ大した意義はない。気をつければファイルの破壊や消失は防げるし、時間をかければ壊れたものはまた生み出せる。ハードディスクの容量がないならば、何千、何万という差分をいちいち保存してもいられない。約束の期日に間に合わなかったとしても、邪悪な竜が復活して世界が3つに引き裂かれるわけではない。しかし、gitが生まれるまでの経緯には、gitが待ち望まれた救世主であるかのように讃えられる十二分な歴史があった。
バージョン管理の概念がなかった頃、コンピュータの中のファイルを共同作業で更新するという工程は阿鼻叫喚と疑心暗鬼の渦巻くカオスの世界であった。無秩序にいつの間にかファイルが更新され、道を歩けば作業が競合し、掴もうとした縄梯子は解け、時に踏み出そうとした足場が足をついた頃にはなくなっている事さえある。
要は、何かの手によって破壊される可能性がある不可逆変化の世界であった。2
gitはこれらの不可逆で実直で荘厳で真実で不条理な「諸行無常、盛者必衰の壊れる世界」にひとすじの光をもたらした秩序の道筋である。先行きはまばゆく、後ろへ引き返すことのできる天の川を我々人類はここに発明した。このような大袈裟な語彙を伴わずとも、多くのエンジニアはこの有用さを直感的に察知し、カオスな宇宙を星屑の道を辿って皆で真っ直ぐ歩めるその希望に心躍らせた。「もう足を踏み外して落ちなくていい」という安堵に身体を預けた。
gitの良さは「プロジェクトの瞬間をファイル単位で管理・保存できること」であるが、それは本質ではない。
「なかったものが生まれた」が正しいのだ。誰もが足を踏み外す危険から逃れ、統一された意識と共に前へ進んで、破壊や消失が起きてしまったものは遡って皆で歴史を改変し、障害にぶつかれば引き返して別の道をやり直すこともできる、そんな暖かい栄光へのルートを引いて示せるようになったのだ。
そしてここで言おう、「この光明の如きgitを導入すれば開発が安全かつ円滑に行えてプロジェクトが破壊されることはない、もう安心だ」という理解、認識は誤りだ。
gitをどのように使えば良いのか
上述したとおり、gitとは事故が起こらないように助ける目的で生み出されたツールである。**事故が起こらないわけではない。**どのように事故を防ぐのかと言えば、誰もがわかる道筋を引いてその道筋を歩めるよう誰かが導く必要がある。
それは宇宙を指せば天の川に例えられ、空では渡り鳥の航空路に、地上ではアリのフェロモンに、電車ではレールに例えることができる。gitとは混沌に秩序をもたらすものである。そして秩序とは、秩序であるが故にシステムとして管理・運営されなければならない。
gitを利用したバージョン管理による恩恵は、システムを企画し、構築し、管理・運営できることでしか得られない。壊れてもいいようにファイルのバックアップを取り続けるのが目的であれば、VS codeの拡張機能で十分に事が足りるのだ。gitを活用するには、その誘導役であるシステムのアドミニストレータ（管理者）が必要であり、そのアドミニストレータによって提供される仕組みは合理的で堅牢で合意がなされるものでなければならない。gitは秩序を作れるツールであるが、決して秩序をひとりでに作るロボットやインストーラーではない。
管理者が引いた線に皆が合意し、連れ立って歩くことによって初めて「おい、決めた道筋から外れてるぞ(戻ってこい)」という注意喚起を作業者同士で行えるようになる。これにより管理者が「できない作業者のミスを埋めて帳尻を合わせる」という管理体制から「作業者同士が互いのミスを認識して互いに埋め合う」という、よりランクの高い管理体制に移行しやすくなる。無論のこと、この管理体制は構築と維持が困難なものであり、それをさらに「助ける」目的で生まれたのがgit-flowないしgithub-flowといった”掟”にあたる概念である。
gitを導入したのち、管理者が独自に設けた「俺ルール」で運用を行おうとしてもなかなか合意は得られない。しかし、有識者同士で集まって決めた世界標準に等しい”掟”ならばどうだろうか。管理者はそれをルールとして提示する必要もなく採用だけ行い、作業者は採用された「gitの掟＝git-flowやgithub-flow」を学べば良いだけである。この掟の登場によりgitの導入コストはグッと下げられたが、俺ルールにせよ世界標準にせよ、その掟が守られているかを監視・保守する必要があるのは変わらない。gitの導入によって「楽になった！安心だ！」と歓喜するのは作業者までであり、管理者はgitシステムという装置と向き合い続けることになるのだ。プロジェクトの安全性を高めるために定めた掟により、管理者はより厳しい秩序を保ち続けなければならなくなる。
つまり、「gitをどのように使えば良いのか」という問いに対しては「ボスの示した掟に従ってボスを助けてあげろ、ボスが迷っているなら掟を提案してやれ」という答えしか提示できない。秩序を秩序たらしめるためには、ボスは管理を行う方法を提示し、子分は管理される方法を把握し承諾する必要があるのだ。子分がいくら「git-flow守りましょうよｗ サイコーっすよｗ」とボスの無知をつついてみても、ボスの示す管理体制に共鳴していないことに幻滅されるのが関の山だ。逆にボスが「これよりgit-flowを施行する！野郎ども、続け！」と意気込んでも、クルーが頭に「？」を浮かべていてはせっかくの秩序は保たれない。秩序が保たれないなら、gitシステムは謳われている最高のパフォーマンスを発揮しない。
gitをどのように使うのかを決めるのは、作業者ではなく管理者だ。作業者は、管理者の定めた掟を受け入れて、その装置が最大速度で走り続けられるよう、装置を理解して管理者に協力してあげるのが栄光への道筋を繋ぎとめる唯一の策だ。また足場がなくなって、混沌の宇宙に落ちていくその無常を、二度と体験しないようにと願いながら。
覚えておくべきこと
- gitはプロジェクトを更新ごとに丸ごと記録してくれるツール
- プロジェクトの状態を巻き戻したり、違う機能が実装されたコピープロジェクトを作ったりできる
- gitのおかげで開発現場の混乱がひとつ解消された、それは大きな躍進で大きな一歩だった
- gitを使って安心安全な体制を実現するためにはその装置をずっと見ててくれる人が要る
- 装置が機能するためのルールを個人が決めても浸透しないから、偉い人たちでgit-flow、github-flowっていうルールを決めた
- gitの恩恵にあやかりたい作業者は管理者が決めてくれたルールを一緒に守ってあげよう。目指す道は同じだから