個人でGitを使うことでなにが得られるのか

🔧002 Gitの基本、みんなでGitを使うとなにがいいのかまでを含めたGitのはなし

Obsidianのデータを同期するのにGitを使う、ということを試して以来、GitとGitHubが大変面白くなってきています。最近は新しく「ひとりプルリク」を始めたりもしていて「Gitとはどういうものか」がだいぶ自然にイメージできるようになってきました。

正直、Obsidianのデータを同期する目的でGitを使うのは「過剰」です。データの同期が目的ならば、MacユーザーならばiCloudを使えば簡単だし、そうでない場合には有料のObsidian Syncを使えうというのがもっとも手軽な方法です。

ObsidianのデータをGitで管理する方法とそのメリット - by goryugo - ナレッジスタック

それでもなんでGitを使っているのか、というな理由は↑に書きましたが、実際どっちかっていうと「面白そうだからやってる」という理由が大きいです。

あとは、一応他にも、GitHubという仕組みを実際に自分で使っていろいろ試してみることで、実践を通じて詳しい使い方を学べたらいいな、とかもあるかな。

で、こうやってある程度実際に自分でGitを使ってみてわかったのは、Git（とGitHub）はやっぱすごい！ということでした。

Obsidianのデータ管理にGitHubを使う必要はないかもしれないけど「書く」行為を重要視する人は少なくとも一度くらいは試してみる価値はある、と感じました。

ということで、今回はそういう感じで、実際にある程度自分でGitを使ってみて、Gitのなにがよかったかというのを改めてまとめてみたいと思います。

難しさの多くは「ローカルルール」

GitとかGitHubといったことばを聞いても、なんかファイルの共有が出来るようになるやつでしょ。それならDropboxとかOneDriveでいいじゃん。しかもなんかGitって黒い画面で使う難しいやつじゃん、みたいなことを思うかもしれません。

確かに、GitやGitHubはDropboxでファイル共有をすることと比べて「難しい」です。Dropboxのようにアプリをインストールしたらそれだけでいきなり使える、というわけではありません。Gitにはシステムで使われる「専門用語」があるし、プロジェクトによって決まりごともいろいろあります。

とはいえ、実は他の人と一緒にGitを使う場合に難しい理由はほとんどが「ローカルルール」です。

このフォルダにはこういうファイルを入れます。日付を書くときは8桁の数字を使います。画像のサイズは、〜ピクセルもしくは比率が4:3にします。

そのようなルールは、複数人でDropboxを使う場合なんかでも決めておいた方がいいルールでしょう。小規模ならばそういうルールはなくてもいいかもしれないけど、規模が大きくなればなるほどかっちりしたルールがないと統制が取れません。

GitHubの「難しい」感じの大半は、このローカルルールです。難しく感じるのは、そこに「ブランチ」だとか「マージ」だとか細かな専門用語が存在するから。

「専門用語」と「専門用語を使ったルール」が混在しているので、それらがごっちゃになって「難しそう」に感じやすいのです。

実際に、自分１人でGitを使うだけならば、難しいことはほとんどなにもありません。究極的な言い方をすれば、１人Gitでやることは「保存」だけです。

この「保存」が特殊なのは、保存の際に「なにをしたのか」を一緒に記録しないといけないこと。そして、すべての「保存」の履歴が残っているので「なにをしたのか」を振り返ることで簡単に過去の「保存」に戻れる、ということ。

とは言え、ただ単純に保存するだけだと「記録が長くなりすぎて振り返りが大変」なので、それをわかりやすくするためにいろんな機能がある。

１人でGitを試す分にはまずそのくらいのことがわかってたら問題ありません。

GitとGitHubはなにが違うのか

一応簡単にGitとGitHubの違いを説明します。

Git（ギット）というのはいわゆる「プログラム」です。Linuxを作ったリーナス・トーバルズさんが、Linuxのプログラムを管理するために作った仕組みがGitというプログラム。

Gitの特徴は「分散型」のデータ管理が得意なこと。ネットワークのどこかに「本体（マスター）」があって、そのデータを扱う人は各自が自分のコンピュータに「コピー（クローン）」を持ちます。それぞれが自分の持っているコピーを編集し、編集したものを本体に「プッシュ」する。こうやって「複数人で分散してデータの管理ができる」のがGitというシステムの大ざっぱな仕組みです。

ではGitHubとはなにかというと、Gitで使う「本体」の置き場所をサービスとして提供している会社です。（GitHub社は2018年にMicrosoftの傘下になった）

Gitで扱うデータの「本体」は、ネットワークに繋がったコンピュータならなんでもいい¹んですが、個人レベルでそれを管理するのは大変です。なので、その「場所」を提供してくれているのがGitHub、というわけです。

このGitHubのおかげでオープンソースプロジェクトへの参加がすごく簡単になったりと、興味深いことはたくさんあるんですが、とりあえずはこのくらいの理解があれば、個人でGitHubを試す分には問題ないと思います。

Obsidianのプラグインをインストールするくらいの根性があればGitは使える

では実際にGitを使うのはどのくらい難しいのか。

ごりゅごより先に仕事でGitを使い始めた妻harunaさん曰く「自分でObsidianのプラグインをインストールするくらいの根性」があればGitを普通に使うくらいのことはできる、とのことです。

実際に、イマドキのGitは「黒い画面」なんてなくても楽勝です。かつてはSource Treeというツールが有名でしたが、今は「GitHub関連の設定が超簡単なGitHub純正のGitHub Desktop」が個人的にはオススメです。

とりあえずGitHubのアカウントを作って、GitHub Desktopをインストールしたらけっこう「なんとなく」でGitは使えるようになります。

GitHub

GitHub Desktop | Simple collaboration from your desktop

なんもわからん、という場合には以下のページをざっと眺めてみるとよいです。

Gitを使ったバージョン管理｜サル先生のGit入門【プロジェクト管理ツールBacklog】

個人レベルでどこが便利なのか

では、Gitという仕組みを個人で使う場合に、いったいどこがどう便利なのか。メリットを一言で簡単にいうと「記録が残せるようになる」ことです。

文章を書いている人で毎日「今日はなにをどこまでやったのか」をきちんと記録している人はおそらく少数派なはずです。

そして、おそらくこのニュースレターを読んでくれている人は「記録がいかに重要なのか」というのはなんとなく理解はされていると思います。

ただ、それでもやっぱり毎回記録を残すのは面倒です。だから、Gitはこの面倒を強制的にやらせます。Git上で保存に相当する「コミット」を行う場合、必ずなんらかのメッセージを残さないと保存が出来ません。これは、どんなに慣れてもめんどくさいんですが、このめんどくさいことを強要するがGitを使う価値なのです。

文章を書いて、一区切りがついたとき。どこまでどういうことを、どういう意図を持って書いたのか。それは、文章を書いたファイル自体に残すのはちょっと変な感じがします。

そういうメッセージを残す場所がGitです。作業ログは別途日誌に残してもいいんですが、それを自然にファイルと紐付けて文章の「メタ・メッセージ」が記録できる。これがGitという仕組みの特徴です。

また、保存（コミット）するたびに「この前とどこが変わったのか」がすぐにわかるので、1日を終えて「今日どのくらい進んだのか」を客観的に把握する手段としても便利に使えます。

ごりゅごがObsidianの履歴を手動で管理してみて1ヶ月ちょっとくらい。最近は、昨日なにをやったのかをまとめて振り返ったりすることにも使っていますが、少なくとも「手間はかかるけど悪くない」と感じています。

まったくもって自動ではないので、毎日毎日手間ひまかかるんですが、これによって丁寧に「今日なにをしたのか」を振り返ることが出来るようになりました。

（実用面で言うと、セミナーの準備をするときに「以前のノート」を簡単に見つけられて、ビフォーアフターを簡単に見せられる、というメリットもありました）

複数人で使うとどこが便利なのか

個人でGitを使う主なメリットは「記録」と「戻れる」ことです。そしてこれが、複数人で使うことを想定すると、大きく変わってきます。

Gitでは、複数人が同時にファイルを変更したときに「間違って上書きしてしまうことがない」ことと、編集内容が衝突した場合の解決方法が良くできていることが一般的な強みとして認識されています。誰がどこを編集したのかもよくわかるようになることもメリットの一つでしょう。

ただ、夫婦でGitを使ってみて感じたGitの便利さは、そういうところではありませんでした。

Gitを使って一番よかったことは、なにも言わなくても「なにをやったのかが相手にちゃんと伝わる」ということでした。

特に自分たちのような「著者と編集者」とは違う、わりと対等な関係性で一緒に本を作ると、どうしても現在の進捗報告が面倒で、曖昧になりがちです。

もちろん、定期的に時間をとって、進捗報告やその後の予定を決めることなどは行っています。とは言え、それとは別に、相手がどのくらいやることやってるかがコミットを見ればわかること。この「押しつけがましくない進捗報告」があるおかげで、双方に適度な緊張感が生まれること。そしてそれを見て、自分もちゃんとやらなければ、という気分になれること。これがGitを使ってもっとも便利だと感じたことでした。

本の原稿をGitHubで共有する

そして、ごりゅごのGit感が変わる出来事が最近もう一つありました。

きっかけは「１人でもブランチを作っておくとログが見やすくなる」という話を聞いたこと。

第百十三回：Tak.さんと原稿のバージョン管理について 作成者：うちあわせCast

この話を聞いて、改めてGitやGitHubについて学んでみたら、GitHubの「Issues」とか「Pull Request」という機能がすごくよくできてることに感動しました。

これはどっちかって言うとGitのすごさというよりGitHubのすごさというイメージなんですが、ある程度使い方を覚えると、複数人でのプロジェクトというのがすごく面白く進められそうです。

たとえば、次にごりゅごが作ろうとしている本の進捗。これは最初は、有料会員の方向けに定期的にニュースレターの中で報告する、みたいなことを考えていたんですが、それだけでなく「希望者にGitHubのプロジェクトを直接見てもらう」ということも出来そうです。

これは、実際に本を作っていく過程を見てもらうというサービスとしても成立しそうだし、実際にそこで「イシュー」とか「プルリク」を送ってもらうということもできそう。Git使ってみるのとかはじめて、っていう場合でも、こっち側でちゃんと設定しておけばデータぐちゃぐちゃになって困る、ということもまず亡さそうなので、思う存分GitHubを試してもらうこともできそうです。

実際のプルリクのやり方なんかはここに書いていけばある程度説明できるし、細かい解説が必要ならばやり方をZoomとかで希望者にやりかたを伝えるのもありかもしれない。

もちろんそんなの興味なくて、ただどんな風に本を作っているのか、人がどんな風にやっているのかを見てみたい、という場合には「見るだけ」もできる。自分としても（有料サービスに加入してくれているという信頼がおける人に）「見られてる感」があるというのは、サボりがちな自分を叱咤激励する効果もあり、たぶんきっといいことばかり。

各自が好きなように自分の好みの距離感で関われるサービスのあり方というのは、これから目指していきたい「丁度いい具合」のサービスの提供の仕方でもあります。

これはもう、思いついたからにはやるしかないですね。

まだGitHubのプロジェクトを作れる段階ではないんですが、ある意味で「そこから」の方が面白いのかもしれません。出来るだけ早く、遅くとも10月中頃には、次のお知らせをお送りできるようにしようと思います。

1. 厳密にはネットワークに繋がっている必要すらないし、コンピュータ1台だけでGitを使うことも可能だが、それにはあまり意味がない。