はじめに

執筆にGitは本当に役立つのでしょうか？　この質問に、私は「はい」と答えたいところではありますが、従来のソフトウェア開発におけるGitの使い方を執筆作業に考えなしにあてはめると、かえって面倒が増えてしまうとも考えています。

この記事では、ソフトウェア開発の経験がある私が、趣味として行うブログ記事の執筆や小説の執筆においてどうGitを活用しているか／活用していきたいか／そもそも活用できるものなのか、について考えをまとめます。

ソフトウェア開発と執筆

まずGitとは何かというと、ファイルの変更履歴を記録し、管理・追跡するときに使う便利なシステムです。いつ、どこを、どう直したかを後から見返したり、少し前の状態で差し戻したりできます。もともとはソフトウェアを開発する人たちが使うシステムですが、文章もデータであるという点ではソフトウェア開発におけるソースコードと変わりなく、理屈の上では同じように管理できます。

しかしながら、ソフトウェア開発の現場と執筆の現場は大きく異なります。例えば、執筆の現場では、多くの人々が同時に並列で1つの文書を執筆していくことはほとんどありません。文書が公開がされるまで、その文書を自分一人でしか編集しない状況も少なくないでしょう。自分一人で趣味で行うソフトウェア開発でGitが大袈裟であることが多いように、自分一人で行う執筆でもGitは大袈裟なことが多いです。

もちろん、Gitが何の役にも立たないわけではありません。もしかしたら、過去のある時点までファイルの内容を戻したい場面があるかもしれませんし、過去のある変更をなかったことにしたい場面があるかもしれません。現在進行形で取り組んでいる編集で、どこがどう変わったのかの情報がリアルタイムで表示されることには、作業の目的を見失わなくなる効果もあるでしょう。

しかし多くの執筆現場は、「常に最新版が正しく、最新版以外には価値がない」という状況になりがちです。果たして過去のある時点のファイルの内容を確認したいことはあるでしょうか？　過去のある変更のみをピンポイントでなかったことにしたい場面はあるでしょうか？　そのようなピンポイントでのドロップやリバートが都合よくできるほどの粒度のコミットとは、果たしてどんなものでしょうか？

もしこれが、自分以外の執筆者がいた場合は話が変わるでしょう。編集者の校閲はパッチやPRのような形式で確認できると便利です。私もアンソロジーへ小説を寄稿した際に強く感じたことです。また、WikipediaなどのWikiシステムは、Gitとは異なるものの、似たようなバージョン管理機能を提供しています。私もWikipediaの編集はしたことがあり、Git的に操作できてほしいと思うくらいには、Gitとの機能的な類似点はありました。

また、文字数を計測し増減を記録するツールや、自動的に公開用データを作ってくれるツールを使っている場合は、編集する度に自動で呼び出されてくれると便利です。これらのツールによって実現される自動化は、ソフトウェア開発においては、継続的インテグレーション・継続的デプロイとして知られています。私もブログ記事の公開において、継続的デプロイを活用しています。

また、AIを使って執筆を手伝わせる場合も、確認しやすく扱いやすい差分（どこがどう変わったか）の概念は欲しいところです。私自身AIを使った執筆はよく行っていて、diffは非常に便利です。

考えなければならないこと

Gitは役に立つ道具です。

• どこがどう変わったかを簡単に確認できる。
• コミットとして履歴を追跡でき、過去のある時点の原稿を確認しやすい。
• ブランチとして環境を隔離し、破壊的な試行がしやすい。
• マージとして複数の編集を1つに統合できる場合がある。
• 自動化ツールとの連携がしやすい。
• 複数の端末で整合性ある同期を取る上でも役立つ。（同期エラーをマージやコンフリクトとして安全に取り扱える。）

しかし逆に言えば、これらができれば、ソフトウェア開発のときのようにはGitを使う必要はないはずなのです。「ソフトウェア開発的なGitの使い方」をそのまま持ち込むのではなく、執筆向けにGitワークフローを再設計する必要があります。

ソフトウェア開発のときのように、コミットメッセージは本当にしっかりと書く必要があるのでしょうか？　適切なメッセージを書くにはコミットの粒度は細かく分けられている必要がありますが、では執筆における粒度とはどう捉えればよいでしょうか？　記事や小説といった執筆対象は、明確な区切りを持たないことが多く、どれだけ頑張って区切ったとしても、それぞれの部分が完全に独立しているわけではありません。区切ることのできないものに対する変更に、どう境界線を引けばよいのでしょうか？

実際のソフトウェア開発において、コミットログを見て変更を把握するのは意外と大変です。あるソースコードが気になったとき、私はよくgit log --unified <filename>して開かれるpagerでdiffを文字列検索したり、git blame <filename>して特定の行についての最新の変更を探ったりしています。

コミットログを元にコードを把握するより、コードを元にコミットを探し、紐付いたIssueやPRのやり取りを読む方がずっと速くて楽なのです。ソフトウェア開発においてもその程度でしかコミットメッセージは役立たないのですから、執筆において事細かく変更について説明していく必要があるかどうかも疑問です。

現在の私が辿り着いた方法

執筆においても、Gitによるバージョン管理は間違いなく役立ちます。しかし、従来のGitの使い方を簡単にあてはめられるほど、執筆とソフトウェア開発は同じではなく、執筆では執筆でのやり方があるはずです。

区切りが良いと感じた時、PCを閉じるとき、休憩前などの「セッション」単位でコミットを行うというのが、私が辿り着いた方法です。

コミットメッセージに日付を含める人も世の中にはいるようですが、これは必要ないと考えています。コミットにはすでに日付の情報が含まれています。また、変更箇所についての情報を書く必要性もありません。コミットにはすでにdiffがあります（技術的には不正確な表現）。要約を書くことの大変さや実用性の薄さを考慮すると、大抵の場合、コミットメッセージは空であっても問題ないでしょう。--allow-emptyは面倒というのであれば、適当にwipとでも書きましょう。それにともない、細かく差し戻すことは最初から想定せず、「履歴さえ残っていれば十分」と割り切ることになります。

ブランチは、何か破壊的な挑戦をする場面では使えるかもしれませんが、大抵の場合は自動化ツールの制御に使う程度でしょうか。mainブランチにのみ継続的デプロイを設定するなどです。ソフトウェア開発における「レビューの単位」「機能単位」という使い方は、一人で黙々と取り組む執筆ではほぼ意味がありません。

Gitを使っていて最も便利だと感じた場面は、複数の端末で整合性ある同期が取れるところでした。従来の自動同期ツールを使っていたときのエラーや不具合は、マージやコンフリクトの概念によってハンドリングできるようになります。常にすべての執筆デバイスをオンラインにしておき、きちんと同期が完了したことを確認してから使用する執筆デバイスを切り替えるという手間は、Gitを使うことでなくなりました。（あまり一般的ではない着眼点かもしれませんが、私の場合は役立ちました。）

おわりに

ぜひとも「ソフトウェア開発において便利なGit」を執筆においても便利に使いたいところではありますが、考えれば考えるほど考えなければならないことが増えていきます。便利な道具をそのまま別の分野に持ち込もうとすると、かえって悩みが増えることがあります。文章を書く人は文章を書く人なりの、無理のない使い方をすればよく、あまり複雑に物事を捉える必要はないのかもしれません。