GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。

【参考】
GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録

GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]

Fujimura ? GitHubで既存のissueに対してpull requestする

hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

bleis-tift/Git-Hooks

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - ＠IT

mikoto20000/redmine_git_branch_hook

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技：ゆめみスタッフブログ)

Git+Redmine+チケット駆動開発のワークフロー

Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers' Blog

GitHub直伝 プルリクエスト活用の3つのコツ | A-Listers

yuroyoro/git-issue ・ GitHub

percolとgit-issueを使って、redmineのチケットをブランチに切って作業するのが捗る設定 | Technology-Gym

Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）：いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - ＠IT

Gitブランチを使いこなすgit-flow／GitHub Flow入門（2）：git-flowのインストールとブランチ運用前のリポジトリ準備 (1/2) - ＠IT

【1】GitHubでも、チケット駆動開発を運用することはもちろん可能だ。
チケット駆動開発の利点であるトレーサビリティを実現するには、コミットログにGitHubのIssueNoを書く運用をすればいい。

しかし、GitHub上でプルリクエストする時には、以下の問題点がある。

(引用開始)
しかし GitHub では、Issue 番号を発行するためには Pull Request を作る必要があり、Pull Request を作るためにはコミットを作る必要がありますが、コミットをする際には予め Issue 番号を知らなければならないため、 Issue 番号付きでのコミットができません。

そのため、しばらくは

1.チケット番号を発行するための Issue をまずは発行する
2.そのチケット番号をコミットログに含めてコミットする
3.その番号とは別に Pull Request を発行する

といった運用をしていました。
一つのトピックに対して、Issue 番号と Pull Request 番号の２つができてしまうため、あまりイケていませんでした。
(引用終了)

GitHubでプルリクエストを行う時、このパッチをマージして下さい、というコメントを書くが、そのチケット番号は新規発行されるために、そのチケット番号をプルリクエストするパッチに紐付けすることができない問題点がある。

【2】解決方法としては、他の記事「GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]」にもあるように、hubコマンドを使う方法があるだろう。

(引用開始)
#例: pullreq ブランチから master ブランチに対して Pull Request を送りたいが、その際に既存の Issue#123 にコードを添付したい

git checkout -b pullreq
hub pull-request -i 123
(引用終了)

GitHub-flowにおけるチケット駆動の運用の問題点 from akipii Oga

【3】上記の記事の問題点は、チケット駆動開発とGitとの相性が良くない点があることに起因しているように思う。
第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題　#RxTStudy: プログラマの思索にも書いたけれど、Gitでチケット単位にトピックブランチを作る運用では、幾つかの問題点が提起されていた。

一つ目は、コミット履歴が故意に改変される危険があること。
これは、特に、trunkの履歴は改変できないように、運用ルールでカバーするしかないだろう。

2つ目は、チケットNo付きトピックブランチで作業していたとしても、trunkへpullする場合、squashで過去のコミット履歴をまとめてパッチ1個で送ろうとすると、新たにチケット番号を付与しなくてはいけないこと。

上記の記事のように、トピックブランチ上のコミット履歴をそのままtrunkに反映する場合は、hubコマンドを使って、トピックブランチと関連付けられたチケット番号を付与してPullRequestすれば良い。

しかし、trunkのコミット履歴には、トピックブランチ上の試行錯誤した履歴は特に欲しくない時もある。
修正のレビューも終わり、完成版のパッチのみを記録したいのが普通だから。

すると、PullRequest用のパッチを作るために、別のブランチを作って操作する必要が出てくる。
そのための新たなチケット番号を作るしか無い。

さらには、本来は、Atlassian製品のように、folkすると自動でチケット番号が付与され、pullされる時にチケットも自動でCloseされるように運用したいのだ。

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

そうなれば、仕様変更や機能追加、障害修正、課題が発生するたびに、チケットを起票する癖がつき、そのチケットに作業履歴を残す運用が徹底される。

また、それらチケットと、トピックブランチが密に関連付けられることによって、何のためにソースを修正しているのか、をいつも自覚するようになるから、ソース修正の意図も明確になる。
プログラミングにはまっていると、ソースを綺麗にしたり、たくさんの機能を追加することに気を取られてしまいがちだから。

【4】トピックブランチとチケット駆動開発の運用ルールや運用方法については、色んなツールが出てきており、試してみる価値があると思っている。

そんなことを思う理由は、チケット駆動開発はTrac＋Subversionの運用が発端であったために、Gitのような優れた分散バージョン管理の機能とチケット管理ツールの連携が不十分な面がまだあるように思えるからだ。

【4-1】例えば、Redmineチケットごとにトピックブランチを「id/12」のように作った場合、bleis-tiftというフックスクリプトを使うと、id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動付与してくれる。

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

bleis-tift/Git-Hooks

このフックスクリプトのメリットは、チケットNo付きトピックブランチをいちいち気にしなくても作業できることだ。
つまり、トピックブランチ上で作業している時、「No Ticket, No Commit」を意識せずとも、ツールが自動補完してくれるわけだ。

【4-2】例えば、「Redmine Git Branch Hook」スクリプトを使うと、トピックブランチをマージするタイミングでRedmineチケットを自動でCloseする運用も可能だ。

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - ＠IT

mikoto20000/redmine_git_branch_hook

このフックスクリプトのメリットは、マージしてトピックブランチが廃止される時に、チケットをCloseする手間を省いてくれることだ。
つまり、Redmine＋SVNで、「fixes #12」でコミットした時にチケットがCloseされる運用をGitのブランチのマージへ適用したものだ。

【4-3】上記の2つの運用は、Gitのトピックブランチ上で「No Ticket, No Commit」「No Ticket, No Merge」をサポートするためのツールといえる。
それらのツールを運用すれば、開発者はトレーサビリティや変更管理、構成管理などの複雑な標準プロセスを意識せずとも、プログラミングに専念するだけでいい。

本来のアジャイルな開発は、複雑で無駄が多い標準プロセスを意識せずとも、プログラミングだけに専念すれば、ユーザに価値あるソフトウェアを即座にリリースできる環境を整えることにあるはずだ。

これらの観点で、分散バージョン管理Gitとチケット管理ツールの相性について、もっと考えてみたいと思う。

【参考】

A successful git branching model and github flow from akipii Oga