Pull Request駆動で小説を開発する

要は、過去のある時点の原稿と、たった今修正した原稿を比較できる仕組みだ。
比較した後、修正後の原稿を正として手軽にコミット(マージ)できる機能も備わっている。

Pull Request の使い方

1. 元ブランチから修正用ブランチを発行する
   GitHub は(正確には Git は)コミット履歴を枝分かれさせ、各々を比較する機能を備えている。
   この分かれた枝それぞれのことをブランチと呼ぶ。

2. 修正用ブランチ上で原稿を修正する
   原稿の修正作業に説明は不要のはずだ。
   適宜修正し、コミットし、プッシュする。
   コミット履歴は修正用ブランチ上に記録されていく。

3. 修正用ブランチから元ブランチに対して Pull Request を発行する
   ある程度コミット履歴が蓄積されたら、いよいよ Pull Request を発行する。
   修正用ブランチ上に記録されたコミットが一覧として表示され、最終的なファイルの変更箇所なども簡単に確認できるようになる。

4. Pull Request で修正を適用するか検討し、必要に応じて原稿を再修正する
   ここも説明は不要のはずだ。
   適宜修正し、修正用ブランチにコミットし、プッシュする。
   修正用ブランチにコミットするたび、Pull Request は自動で更新されていく。
   (Pull Request 発行後、元ブランチにコミットしても自動では反映されないので注意)

5. 修正が完了したら、修正用ブランチを元ブランチにマージする
   「Merge pull request」からマージすることで、修正用ブランチ上で修正した原稿が元ブランチに保存される。
   必要に応じて修正用ブランチを削除したり、継続して使用したりする。
   そのあたりの思想は千差万別なので、ここで言及はしない。
   GitHub Flowで検索すると頭が痛くなること請け合いなので、検索してみるといい。

情報整理の場としての Pull Request

上記の流れで Pull Request を使っていくと、自ずとコミット履歴は分割・整理されていき、検索性が上がる。
コミット履歴を直接確認するのではなく、当時作成した Pull Request から辿ればいいからだ。
Pull Request にはコメントを投稿する機能もあるから、それらを駆使すれば更にわかりやすく整理できる。
私の場合は、自分の原稿に対するツッコミや悩んでいることを適当に投稿している。

Pull Request のメリットは、コミット履歴の分割に留まらない。
ある一時点からのコミット履歴が積み重なることで、直近のペースが目に見えてわかるようになる。
仮に原稿修正のペースが落ちてしまっても、コメントに案レベルの修正を書き込むことで進捗を生み出せる。
思いついた設定や伏線をコメントすることで、プロットへ転記する前に忘れてしまう悲劇を回避できる。

Pull Request はファイルごとに作成してもいいし、修正したい内容に応じて作成してもいい。
Issue にするほどでもない課題でも、Pull Request のコメントなら気軽に書き込んでしまっていい。
適当に作成して、適当に原稿を修正して、適当に情報を放り込んで、適当にマージする。
マージしたあとも Pull Request 自体は閲覧できるから、適宜そこから必要な情報にアクセスすればよい。

校正の場としての Pull Request

先の記事で textlint を紹介した。

name: reviewdog
on: [pull_request]
jobs:
  textlint:
    name: runner / textlint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - name: textlint-github-pr-review
        uses: tsuyoshicho/action-textlint@v3
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-pr-review
          level: warning
          textlint_flags: "episodes/**"