Atlassian製品による「No Ticket, No fork!」

Atlassian製品による「No Ticket, No fork!」に関する記事をリンクしておく。

GreenHopper を使用した Bamboo と Bitbucket の自動化 | Atlassian Japan

(引用開始)
率直に言って、チームが 課題ごとに開発ブランチを作成する慣習 を採用 (または検討) していない限り、上記の手法にこだわる必要はありません。 この手法には 3 つの意義があります。1 つ目として、ブランチ作成、マスターへの最終マージ、およびブランチの削除が自動化されます。これによって課題の実装にかかる時間が何時間も短縮されるというものではありません。しかし、開発者の作業項目からいくつかの管理タスクを省いてくれます。また、ストーリー ブランチの実践も促します (チームがそうすると決めた場合)。しかも、しつこくメールをしたり、井戸端会議で愚痴を言ったり、チーム ミーティングをしたりすることなく、洗練されたやり方でそれが実施されます。3 つ目として、これらのブランチに対する命名規則が自動化されます。チームのレポジトリ内のブランチを見るときに格段に見分けやすくなります。
(引用終了)

課題・障害・タスクのチケット単位にブランチを派生し、更新して、ブランチをmasterへマージする時にチケットも同時にCloseする方法が公開されている。
この手法は、チケットをトピックブランチ(ストーリーブランチ)とみなした場合によく使われるだろう。

この手法の利点は上記には3つ挙げられている。

(1)ブランチ作成、マスターへの最終マージ、ブランチ削除を自動化
(2)メンバーにチケット単位にストーリーブランチを作ることを促す
(3)ブランチに対する命名規則が自動化される

目を惹くのは(2)におけるチームへの影響だ。
バグ修正や機能改善、リファクタリングなど、開発者個人の作業は必ずブランチ上で更新され、masterへ最終マージされる運用が自然に促される。
いや、むしろ強制されるといって良い。
その運用によって、masterへのマージ時にコードレビューするタイミングが生まれたり、ブランチ上で試行錯誤する空間を得られることで自由に開発できる、などの利点が生まれる。

ツールがチームにプロセス改善を促す良い事例の一つだと思う。