ソフトウェア開発におけるソースコードの管理には Git + GitHub 等のホスティングサービスが利用される．開発を進める上でのブランチの運用方法は色々あるが（例えば Git-Flow など），本記事では，最近筆者が覚えた issue，Pull Request（PR） ベースの開発手順を扱う．
なお，タイトルには GitHub と書いたが，Git リポジトリのホスティングサービスは GitLab でも Bitbucket でも本質的にはなんら変わりはない．
issue，PR ベースの開発
issue を立て，その issue に基づいてブランチを切って PR を出す，という流れである．チームでブランチをどう運用するかという合意形成が出来ている前提で話を進める．
Issue，PR ベースの利点
- 機能やバグ修正など，実装が必要なものを常に GitHub 上で確認できる
- 機能，実装に関する議論を issue という形でリポジトリに紐づけて残すことができる
- 他の人（主にレビュワー）が「今どこまで実装できているか」を把握しやすい．実装が全部終わってから PR を出すよりも，実装の過程が GitHub 上で可視化されているため，開発者，レビュワーの双方の心に良さそう（語彙力）．
個人的にはプロジェクトのベースができるまでは develop ブランチにコミットして，必要最低限の機能が出来たら issue，PR ベースで進めると良さそう．
手順
下記の手順で開発を進めていく．あくまでも手順のメモなので，それぞれの手順で何を書くべきかという議論はしない．
- GitHub 上で issue を立てる
issues/[issue number]でブランチを切り，空 commit & push- GitHub 上で PR を作成する
- タイトルに
WIP:という prefix を付ける - タイトルに issue 番号を入れる
- 実装する
- 実装が終わったら
WIP:prefix を除去してレビュー依頼 - LGTM ならマージ
1. GitHub 上で issue を立てる
GitHub で issue を立てるだけ．タイトルの付け方や内容の粒度などは，チームで予め決めておく必要がある．
- issue のタイトルの例
エンドポイント "/new-endpoint" の実装
2. issues/[issue number] でブランチを切り，空 commit & push
例えば，立てた issue の番号を 14 とする．
$ git switch -c issues/14 $ git commit --allow-empty -m "Start issue #14" $ git push origin issues/14
3. GitHub 上で PR を作成する
PR のタイトルには WIP: という「作業中」（Work In Progress）を表す prefix を付けると良い．また，タイトルに issue 番号を入れておくと，どの issue についての PR かが一目で分かるのでおすすめ（コントリビュートの規約でこういった決まりを定めている OSS も多数ある）．
- PR のタイトルの例
WIP: Refs #14. Implement endpoint "/new-endpoint"WIP: Refs #25. Bugfix: "/new-endpoint" response's schema"
4. 実装する
適宜 push するとどこまで実装できているかがレビュワーが把握しやすい（かも）．
5. 実装が終わったら WIP: prefix を除去してレビュー依頼
PR のタイトルの WIP: を外して，レビューを依頼する．LGTM が付くまで修正．
6. LGTM ならマージ
LGTM が付いたのでマージ．
補足
本記事では WIP で作業中を表しているが，GitHub では Draft Pull Request という「この PR は作業中です」を表す機能がある．これを利用すると PR のステータスが "Draft Pull Request" の間はマージ出来ない仕組みになっている．
