git（ギット）に関して、そろそろ名前ぐらいは聞いたことがある方も増えてきたと思う。gitは「ソースコード管理ソフト」あるいは「バージョン管理ソフト」などと呼ばれるカテゴリになるソフトウェアだ。Linuxカーネルの開発のために作られたので、大規模な開発プロジェクトでの実績は「折り紙付き」である。
実際のところ、gitは、ファイルやフォルダーになっていれば、プログラムでなくても扱うことができる。ファイルはソースコードなどと同じくテキストになっているほうが扱いやすいが、画像ファイルなどバイナリファイルを含めることも可能だ。ソースコードだけでなく、テキストやXMLでの設定、構成ファイル、Webページなども対象にできる。書籍の原稿や論文のような比較的作成に時間が掛かるテキストを推敲したり、書き換えたりしていくとき、gitでバージョン管理しておくと、簡単に前の段階に戻すことが可能だ。
このgit、開発者が地理的に広がって作業を可能にすることから、個人用PCとサーバーで分散して作業を進められる「分散型」と呼ばれるタイプのソースコード管理ソフトだ。簡単に言うと「リポジトリ」というプロジェクトのソースコードを納めたデータを、サーバー側（リモートと呼ぶことがある）のリポジトリからコピーしてきて、ローカルに置いて作業する。必要なファイルはすべて手元にあるので、参照がローカルで完結できる。gitなどのソースコード管理ソフトウェアでは、個々のユーザーか行った修正を他人の修正に上書きしないように個別に管理できる。
簡単にいうと、gitは、指定したディレクトリ、ファイルのコピーをリポジトリに取り込んで記録していく。取り込むタイミングやファイル、ディレクトリは、ユーザーが指定する。この操作をコミット（Commit）という。だったら単にファイルのバックアップやアーカイブと同じように見えるが、gitがgitたるゆえんは、コミットをツリー構造として管理できるところにある。
この機能を「ブランチ」と呼ぶ。ブランチは、簡単にいうと作業を２つに分岐させるための方法だ。たとえば、片方はバージョン2.0の開発、もう一方は、バージョン１のバグ修正版1.1の開発といった使い方をする。
gitの特徴は、こうして2つに枝別れさせても、マージという機能を使って、前記の例ならバージョン1.1のバグ修正を反映させたバージョン2.0を「半自動」で作ることができる点だ。半自動というのは、人間でないと判断が付かない場合がありえるからだ。マージは、元になるコミットと変更部分を反映させたいコミットを使って、新しいコミットを作る。
gitの場合、3Wayマージと呼ばれる手法で、単純な修正ならほぼ自動でマージできる。もしブランチ後の作業によりAというソースコードがBとCという異なるソースコードになったとき、両方の祖先となるAを加えた3つで差分を判断しする。これによりBで修正されている部分、Cで修正されている部分、変わらない部分（Aと同じ）が判定できる。
BとCの変更点が異なる場所であれば、Bの変更点をCに反映させる（マージ）することが可能だが、同じ部分を修正していた場合には、人間がどうするのかを判断（場合によっては手動で書き換え）を行う必要がある。実際にはもっと複雑で直接の祖先が1つに特定できないときに過去のコミットからマージを行って、仮想的な先祖を作るといったことも行われる。
gitに限らず、ソースコード管理システムでは、ファイル保存のさらに上の概念として、「コミット」のようにリポジトリにソースを反映させる操作が入る。とりあえずテストをパスするなど、作業が一段落した時点で、コミットするという習慣を付ける必要がある。この考え方に慣れるには少し時間がかかる。熱中すると、コミットしないまま作業を進めてしまって、行き詰まって元に戻したいと考えたときに前回のコミットが遙か昔だったなんてことがあるからだ。ムダなコミットは無視すればいいが、コミットしていない状態には戻すことができない、これだけは肝に銘じておく必要がある。
かつて、外出先でインターネット接続がままならない時代には、筆者は、原稿執筆用にgitを利用したこともあった。ただ、原稿などの執筆では、ブランチさせる必要がほとんどなく、最近は外出先でもインターネット接続が簡単に行えるため、原稿書きのようなブランチがほとんと必要ない作業は、オンラインストレージのほうが便利だ。
今回のタイトルの元ネタは、フランスの女優ブリジット・バルドー（Brigitte Bardot）の映画「裸で御免なさい」である。バルドーの「キャピ、キャピ」っとした感じが単に筆者の好みだったからである。なぜ、これがネタになりうるのかというと「ブリジット」という名前は、ケルト神話の女神である“Brigit”（ブリギット）に由来するからだ（ここでようやくギット）。