どうも。つじけ（tsujikenzo）です。このシリーズでは2021年1月から受講している「ノンプロ研ライティング講座初級1期」について受講メモをまとめています。全8回の今日は第7回目です。オーラス前です。
※この記事に使用している画像は、講座のスライドから使用しておりますが、すべて著作権者の許諾を得ているものです。画像の無断コピーや転載は、改正著作権法に抵触する恐れがありますので、ご注意ください。
前回までのおさらい
前回は「Webライティング」についてお届けしました。「記事が書かかれる場所」や「流入経路」を意識することによって「読者に最高の体験を提供しよう」という内容でした。
今回は「Git・GitHubによる共同編集」をお送りします。
今日のアジェンダ
- Gitとは
- GitHubとは
- 共同執筆環境を整える
Gitとは
Gitは、PC内でファイルの「バージョン管理」をするツールです。今まで事務作業を行う場合、バージョン管理と言えばほとんど「ファイル名」や「フォルダ名」で管理することが多かったと思います。
しかし、「最終版」というファイルが複数あったり、「○○コピー」というファイルがあって、重要なのか破棄していいのか分からない、という経験をした方も多いと思います。
管理すべきファイルの数や内容など、規模が大きくなっていったり、チームで共同編集するようになった場合は、「バージョン管理」を正しく行う必要があります。
その手助けをしてくれるツールが「Git」です。
Gitでできること
聞いたことある用語がいくつかありますが、ちゃんと知らないことばかりです。一つ一つ操作をしながら慣れていきましょう。
Gitは（Windowsだと）Git Bashというコマンドラインインターフェイスで操作します。いわゆる黒い画面というやつです。
Gitで使用するコマンドはこのようなものがあります。数はそこまで多くなさそうです。
バージョン管理は「プロジェクト単位」
先日のブログで（正確に合っているかどうかわかりませんが）、ちょうど「プロジェクトとはなにか」というお話をしました。
テキストベースのファイルを管理していく場合は、「フォルダ」がプロジェクトに該当しますので、Pythonのようなイメージと近いかもしれません。
- 「プロジェクトの更新」を「記録する」ことを「コミット」と呼びます
- 「コミットの履歴」の格納場所を「リポジトリ」と呼びます
- 「プロジェクトの履歴」は分岐可能です。「分岐の枝」を「ブランチ」と呼びます
履歴の分岐とマージ
チャレンジングな変更を行うときなどは、変更の履歴に「ブランチ」をつけます。
もし、チャレンジングなブランチがうまく言っている場合は、再びメインブランチとして、作業をすすめることができます。（もちろんチャレンジングブランチを破棄することもできます。）
ブランチを統合することを「マージ」と呼びます。Gitでは「コミットする」「ブランチを切る」「マージする」を繰り返していくことになります。
さて、これまでは「1人で1つ」のリポジトリ内のコミット、ブランチ、マージを管理するお話でした。リポジトリは「ローカルのPC内」にあります。
ここで、「共同作業者」や「編集者」などの、ネットワーク外にリポジトリを共有したい第三者がいる場合は、どのように管理・運用したらよいでしょうか。
GitHub（ギットハブ）とは
「ソフトウェア開発プラットフォーム」です。Gitが「ローカルリポジトリの管理」をしていたとするなら、GitHubは「リモートリポジトリの作成、管理、共有」するクラウド上のサービスということです。
クラウド上にありますので、ユーザーどうしのやりとりも円滑に行えます。リポジトリのハブのような機能をもちますので、「GitHub」というネーミングなわけです。
編集者による準備作業
まずは、編集者がプロジェクト単位の「リモートリポジトリ」をGitHub上に作成します。これはリポジトリなので、ゆくゆくはファイルが作成され、バージョン履歴を置く作業場になります。
編集者が作業をする際は、リモートリポジトリをローカルに落とし込む必要があります。これが「クローン」です。クラウド上からPCに複製を作成するということですが、「クローン」という単語を使います。
編集者はまずなにかしらのコミットをして（初回はなんでもいいようです。）、そのコミットをリモートリポジトリに「プッシュ」します。これで、リモートリポジトリとローカルリポジトリが同じ状態になっているはずです。
共同作業者の招待
ここまで作業場の準備ができたら、共同執筆者や共同作業者を「リモートリポジトリ」に招待します。
執筆者は、自分用のブランチを切って、作業を開始します。一人で作業をしていたときと同じように、変更履歴を「コミット」しながら作業をすすめます。
ある程度コミットして、編集者にチェックしてもらいたいなという場合は、コミットをリモートリポジトリにプッシュします。（ここではまだマージしていません）
執筆者からプッシュされたことを、編集者に通知することを「プルリクエスト」と呼びます。
プルリクエストとは
- リモートリポジトリ上のブランチの変更をレビュアーに通知する
- レビューとマージをお願いする
システム開発では、マージを担当するのが開発チームのリーダーだったりします。
レビューのパターン
編集者の最終的なゴールは「リモートリポジトリをレビューしてマージする」ということです。レビューした結果、要修正かどうかで、以下のような対応が必要になります。
- 問題なければ、プルリクエストをそのままマージする
- レビューを送信して、修正してもらう。再度コミット＆プッシュしてもらう
- 編集者が簡単に修正できるものだったら、直接修正して、コミットしてマージする
修正を依頼された執筆者は、編集者によりリモートリポジトリ上で行われた変更を取り込むために「プル」をします。（ここがクローンではないのが少し混乱しますね。）
執筆者は自分用のブランチを切って、作業を始めることになります。
共同執筆環境を整える
講座では実際に講師陣を「編集者」、受講生を「執筆者」と見立てて、GitHub上のリモートリポジトリにプルリクエストしたり、ハンズオンを行いました。
実際に、Gitのインストールや、ブランチの切り方などはこちらのシリーズを順に追っていけば、スムーズに学べると思います。
私も分からないことがあれば、つど確認していこうと思います。慣れるまではたくさん触って、たくさんプルリクエストしてみるしかないかなとも思ったりしてます。
まとめ
以上で、Day7の振り返りでした。プログラミングでいつか利用してみたいと思っていたGitHubが、ライティング講座で学べるとは思っていませんでした。しかも、とてもわかりやすい内容になっていたので、挫折せずにインストールすることができました。
これから、色んな場面でGitHubを利用していきたいと思います。次回は最終回で、「書籍の企画と執筆」をお送りします。
※「この一週間でやったことDay7」も追記しています。
この一週間でやったことDay1
- 『生命科学的思考』を読む（読了）
- 速読について調べる（体験申し込み）
- ネタメモ用フォームの要件定義（完成）
- タイピング部再入部（記録シート完成）
- ネタのリマインドの要件定義
この一週間でやったことDay2
- 『遅いインターネット』を読む（読了）
- 思い付きやアイディアつぶやき用のフォーム作成とスプレッドシート完成
- 地元の速読教室に体験へ
- noteのTwitterアナリティクスレポートを読む
- Notionを触ってみる
この一週間でやったことDay3
- 『世界は贈与でできている』を読む（読了）
- Markdownについて考える
- アドオンが調子悪かったがいけそうなので新たな体制を整えた
この一週間でやったことDay4
- 『アウトプット大全』を読む（読了）
- 『OKR』を読む（読了）
- 『速読らくらくエクササイズ』を読む
- ドキュメントからWordPress投稿のブログをUP
- 大河ドラマについてまとめるNotionを始める
この一週間でやったことDay5
- 胃腸炎からの回復
この一週間でやったことDay6
- 『アジャイル開発とスクラム』を読む（読了）
- 社内スクラム開発に向けてドキュメント書いた。20000字。
- HHKB Professional HYBRID(JS配列)買う
- ブログにディスクリプションを設定する
この一週間でやったことDay7
- サーバーの契約更新。36か月。
- 社内でスクラム開発ごっこを始める
- ブログが100本に到達。イベントはやらなかった。
- GAS初級（講師）、VBA中級（クラス）でメモリフルです
