シェア
はてブ
Findy Engineer Lab編集部のゆでたまご（@f43a9a）です。いつもお世話になっております。
前回からのあらすじ
メディア運用にGitHubを使う際のプラン選びを行う
「まずは無料プランから」と、組織Freeプランを選択
アドバイザー: 武藤健志さん（@kmuto）
ITエンジニアリングを活用した技術系書籍づくりに豊富な経験があり、現在は株式会社はてなでエンジニアとして働いている。「Re:VIEW」開発者。
Organizionを作る
まずは社内の情シスの方に「編集部GitHub化していいですか？」と相談。そしたら、いつの間にかFindyEditorialDepartmentというOrganizationができていました。ありがとうございます！
「詳しい人にお願いしたら、うまくいきました！」では記事コンセプト的にマズいので、自分でも一通りの流れを試してみましたが「Settings > Organizations > New organizationと飛んだら、あとはアカウント作成のよくある流れで作れる」という感じでした。こういったGitHubの基本的な操作方法については、Chat with Copilotで質問しても教えてもらえるはず。
作業自体はボタンをポチポチしていけば何とかなるので、知識がなくてもできるはず。しかし、Findy Engineer Labのように運営母体が企業の場合は、「誰をオーナーに設定するのか」「登録するメールアドレスにはどれを使うのか」などの設定や調整が必要になり、そこで「社内の誰か詳しい人に相談する」というステップが発生するのではないかと思います。下記のような運用ルールも決めたほうがいいでしょうしね。
Findy Engineer LabのOrganization運用ルール
原則、リポジトリはPrivateで作成（原稿などはそこで管理すること）
運用メンバー（編集部）に以下の権限を付与する（記事制作進行に必要な操作ができるようにする）
メンバー（取材対象者、ライターなど記事ごとに変わる関係者）の追加・削除
リポジトリ作成・権限変更
運用メンバーでアカウントの棚卸を定期的に行う（不要な権限・過剰な権限を渡すのはNG。定期的な見直しもしてミスなく運用すること）
- メンバーやコラボレーターの権限見直し
情シスの方と相談して決めた内容はだいたいこんな感じ（まるかっこは本記事向けの補足説明として追記）。
GitHubで記事制作を行うには
――Google Docsで行っていた原稿制作・共有・レビューに、GitHubを利用するうえで、押さえておくべきポイントは？
武藤さん：そうですね。ライティングに加えレビューまで行うとなると、GitHubの機能をフル活用することになります。1人で書くだけならバックアップ程度の意味合いにしかなりませんが、複数のメンバーで共同作業を行う場合、GitHubが真価を発揮します。流れとしてはこんな感じになります。
リポジトリを作る
ブランチを切り、チェックアウトして、原稿を書く
プルリクエストを出し、他の人（レビュアー）してもらう
新しいブランチを作成して、修正、コメント、サジェスチョンの内容をマージ
プルリクエストを出し、レビューしてもらう
これを繰り返して、記事をブラッシュアップしていくのが良いと思います。ブランチやプルリクエストの概念が入ってくるので、最初は難しく感じるかもしれませんが、直接コミットするよりもブランチを切って作業したほうが良いと思います。コンフリクト（複数のブランチで同じ範囲を変更しようとしたときに発生する競合状態）が起きたときも分かりやすいですし。
ブランチの機能は、表記統一の際にも便利で、編集ブランチからさらにブランチを切って、一括で表記統一を行い新たなプルリクエストを立てる方法があります。そして、良さそうであれば元の編集ブランチにマージするという手順です。
ファーストステップでは、Web上で作業を完結させるのが良いでしょう。覚えることを最小限に抑えられます。ですが、オススメしたいのはコマンドラインを使って原稿をローカルで管理し、使い慣れたエディターで記事制作を進めるやり方です。
Windowsの場合は、Gitをインストール必要があるため、少しハードルが上がるかもしれません。ダウンロードはgit-scm.comから行えます。
エンジニアが文章を書くときはVisual Studio Code（VS Code）を使うことが多いと思うのですが、このエディターとGitの連携も簡単です。VS Code上でGitを操作する方法についても、情報が多いので調べてみてください。こちらの場合は、手元にリポジトリをクローンし、ブランチを作成、コミット・プッシュして、GitHub上でマージする流れになりますね。
VS Codeには、その他にもMarkdownのプレビュー機能があったり、拡張機能が豊富だったり。コーディングだけでなく記事制作にも役立つと思います。ちなみに私が文章を書くときはEmacsをよく使うのですが、万人向けではないと思うので、今回はオススメはしません。
実際にGitHubを使ってみよう……と思ったが、用語が難しすぎて詰まる
さて、実際に手を動かしてみましょう。ファーストステップとして紹介してもらった「Web上で完結する方法」にチャレンジします。
リポジトリを作る
ブランチを切り、チェックアウトして、原稿を書く
プルリクエストを出し、他の人（レビュアー）してもらう
新しいブランチを作成して、修正、コメント、サジェスチョンの内容をマージ
プルリクエストを出し、レビューしてもらう
「1.リポジトリを作る」までは、GitHubのボタンをポチポチ押していったら何とかなったのですが、それ以降のステップでつまずきました。
ブランチって何？ 枝分かれするイメージで合っているのか？
ブランチを「切る」って何？ 切るというより生やしていないか？
「チェックアウト」って何？ 辞書を調べたら「ホテルのチェックアウト」「調べる」「精算する」などの意味が出てきたんだけど、どれなの？*1
「プルリクエスト」って何？ 本当に何？ 「プル」も「リクエスト」も分からない
いや本当は非エンジニアの私でも、ちゃんと調べたら分かると言えば分かる。だけどこんな難しい用語だらけのものを、どうやって他人に教えたらいいのかが分からない
これは頭だけで理解しようとするより、実際に手を動かしたほうが早いかも？ 次回は「Web上で完結する方法」にチャレンジして、その工程を記事として紹介します（という名目で、社内向けのマニュアルを作ります）。
*1:Gitのcheckoutコマンドでは「ブランチを切り替える」操作ができる、と後に知ってビックリした。辞書の意味と違いすぎません？ さらにその他にも「ファイルやディレクトリの復元」「ステージングエリアの変更を取り消し」などの操作に使えると知り、もう一回ビックリした
