情報整理ダイアローグ第二十一回:個人と共同のGit
前回は、テキストファイルを利用している話をした。プレーンなテキストファイルはいろいろと「操作」がしやすくて便利である。
そのテキストファイルについて二つ付け加えたい話がある。ややマニアックになるが、そういうマニアックさを受け入れてくれるのがテキストファイルの良さでもあるので、ぜひとも紹介しておきたい。
まずはGitについて。
■ローカルのバックアップ
私のテキストファイルは、基本的にDropboxに保存してあるのでバックアップは心配ないが、それに加えてGitも利用している。
Gitとは何か。
よし、ググろう。
簡単に言えばバージョン管理ツールである。基本的には大掛かりなソフトウェア開発に利用されるが、こぢんまりした使い方ができないわけではない。特にGitHubは、プライベートな利用でも無制限にリポジトリ（プロジェクトの単位のようなもの）を作れるので、かなり気楽に使い始めることができる。
私は、書籍執筆のような大きなプロジェクトに関してGitを使うようにしている。GItHubでプライベートなリポジトリを作り、それを私のパソコンのローカルフォルダと同期させておく。
このような管理を行うと、二つの点でメリットがある。一つは、大規模な修正をした後に、自由に「昔に戻す」ことができる点。この機能があるおかげでうじうじ悩むことなく「いっちょ手を加えてみるか」という気持ちなりやすい。そういう物書き心理的安全性の確立はけっこう大切なことだ。
もう一つは、作業毎にコミットログを残すようにしているので、それが「進捗の足跡」になる点。自分が、どれだけ進んできたのかが可視化される。それはモチベーションを下支えしてくれる重要な情報となる。過去のタスクリストも同様の働きをしてくれるが、コミットログは単一のプロジェクトのみの、しかもかなり細かい「足跡」が残せる。これはなかなか嬉しい。
■ブログ代わりに
Gitのもう一つの利用方法は、ホスティングサービスを利用した「ブログ」の運用である。
技術的な話は割愛するが、GitHubとNetlifyを使い、静的サイトジェネレーターとしてHugoを用いることで、ローカルのmdファイルに記事を書けば（そしてそれをpushすれば）、その内容がブログとして公開されるように設定している。
これがとんでもなくラクチンである。ブラウザからどこかのダッシュボードに「ログイン」する必要がない。すべてローカルのテキストエディタ（つまりVS Code）で完結してしまう。正直なところ、メインのブログもこのスタイルに変更したいのだが、なかなか大掛かりな作業となるのでまだ着手できないでいる。
ともかく便利な仕組みだ。
■共同作業として
もう一つ、Gitの重要な役割が共同作業の場である。というか、これこそがGitの真骨頂であろう。
二人以上で進めるプロジェクト（だいたいは執筆プロジェクト）において、リポジトリを共有し、お互いが自分のローカルで作業を進め、その成果をpushする。
設定しておくと、pushされたら自分宛にメールが届くので、それが良い感じの「リマイダ」となる。強制的な作業の要請というよりは、「ああ、自分もそろそろ何かしようかな」という感覚を呼び起こす程度のリマインダだ。
遠隔地で、非同期で、複数人で作業を進める場合、いろいろなクラウドツールの選択肢があるが、やたらめったら高機能なものを求めない限り、Gitで十分という感覚がある。どちらにせよ成果物のファイルは共有する必要があり、その延長線上でコメントやタスクなどが管理できたら、もうそれでいい。あとは、メールでのやわからいリマインダが作業を（ある程度は）促してくれる。ほどよい「管理」である。
■さいごに
最初に述べたように、テキストファイル群はすべてDropboxに保存しているので、その役割としてのGitは「別になくても構わない」とは言える。それでも、意図的な（あるいは意志的な）「コミット」が残っている点は大きいし、ブログや共同作業に関してはGItであるからこそ、という部分がある。
でもって、こうしたことが自由にできるのはテキストファイルベースだからである。たしかにクラウド型のツールでも共有やらなんやらは可能だが、その「自由さ」に関してはテキストファイルベースにはかなわないのではないかという気がする。
この記事が気に入ったらサポートをしてみませんか？