VimプラグインのGitHubでのブランチ運用について

Vim プラグイン は Git flow 的なブランチ運用した方がいい気がしてきた - Humanity

上記記事から半月程経過したので現状のブランチの運用についてさらに考えをまとめる。

あとこの記事を書いてる途中、現在の運用について不要な労力を割いている箇所が見つかった(詳しくは以下を参照)ので新しいブランチ運用についても書く。 ちなみに「現在のブランチ運用状況」を適用してるのはcaw.vimのリポジトリ。

タイトルについて

わざわざ「Vim プラグイン」とタイトルに付けてるのはやはりこういった運用方法というのはリリース先 (vim.org) や人によって色々求めてるものが違うから参考にしてほしい位の意味合いで付けた。 あと、やはり現状のブランチ運用を自分の頭の中で整理する記事でもあるので、これからどんどん変わっていく予定というのもある。

自分が求めてるものとか

• なるべくブランチ作りたくない
• でも PR や issue 単位でコードに変更を加えていくと、コード以外の領域で変更に対するコメントを書けるので便利
• できれば将来は changelog は自動生成したいので、自動生成しやすい運用を考えたい

現在のブランチ運用状況

• master ブランチ
  • feature ブランチや fix ブランチが完了した時点で本ブランチに都度マージしていく
• feature ブランチ あるいは fix ブランチ
  • 新規機能あるいは修正用 マージする時は master ブランチと release ブランチ両方にマージする
• release ブランチ
  • vim.org へのリリース用。changelog を書くために作る意味合いが強い

次期ブランチ運用

現在のブランチ運用を書いてる途中「あれ？releaseってこれブランチ切る必要あるの？issue で十分じゃね？」と至極当然な感想を抱いたので以下のようにする。

• master ブランチ
  • feature ブランチや fix ブランチが完了した時点で本ブランチに都度マージしていく
• feature ブランチ あるいは fix ブランチ
  • 新規機能あるいは修正用ブランチ。 マージする時は master ブランチにマージする

GitHub のボタンからマージすれば事が済むので便利。

しかし誰かからPRを送ってもらった場合はこのブランチ名に則っているとは限らない。 CONTRIBUTING.mdに書いて「できれば則ってもらう」程度にしたい。

次期ブランチの運用フローについて

上記ではブランチの役割は書いたけど運用フローについてあまり触れてなかったのでもう少し書く。

• リリースが終わると次のリリースのための issue が作成される。その issue で行われるのは
  • changelog の作成 (現在は手動)
  • 次のリリースで取り込む機能(feature ブランチ)とバグ修正(fix ブランチ)の選別
• 初期リリースでは changelog の作成は行われない
• 重大なバグがあったら緊急リリースされる (「GitHub issues の次期ラベル運用」「バージョン番号の運用予定」も参照)

上記の様に運用していけば changelog の自動生成も楽そう、という目論見。

GitHub issues の現状のラベル運用

これも改善の余地がありそう。

• next
  • 時期リリースのためのラベル
• todo
  • feature ブランチで閉じられる運命の issues に対して付けられる
• bug
  • fix ブランチで閉じられる運命の issues に対して付けられる
• announce
  • アナウンス用。重大なバグがあったりした場合は付けてた
  • 参考リンク：Error "Can't open i.vim" on MS Windows (and maybe Mac OS X) · Issue #37 · tyru/caw.vim · GitHub

GitHub issues の次期ラベル運用

• release/{バージョン番号} (v1.0 の場合は release/v1.0)
  • バージョン番号の運用については次項で解説
• todo
  • 変わらず
• bug
  • 変わらず

announce ラベルは要らない。 PR か issues があればいいはず。

もし重大なバグがあったら緊急リリース(ラベルとバージョン番号は v1.0a のようになる予定)のための issue を作ればいい。

バージョン番号の運用予定

これだけタイトルが「現状の運用」でも「次期運用」でもないのはまだcaw.vimでリリースを経験してないからです…

基本「v1.0」のように付けられて、緊急リリースの時は末尾にアルファベットが付きます。

• v1.0a (v1.0 に対する緊急リリース)
• v1.0b (v1.0a でもまだ重大なバグがあった場合)

メジャー番号とマイナー番号の役割はこんな感じ。

• メジャー番号：互換性が壊れる変更だった場合に繰り上げられる。その際マイナー番号は0にリセットされる
• マイナー番号：互換性が壊れない場合は繰り上げられる。緊急リリースの場合は上げられない (v1.0→v1.0a)

次期ブランチ運用に向けて (TODO)

とりあえず現状の運用を上記の様に変えるためのタスク。 とりあえず下記タスクを issues に上げたい。

• release ブランチの削除
  • 今の release ブランチでの作業は別PRに分ける
• announce ラベルの削除
• CONTRIBUTING.md にブランチの運用について書く

おまけ：changelog の自動生成について

今考えている changelog の自動生成の方法について少し書く。

• リリース用の issue の本文に決まった形式でタイトルを引用する PR 番号を書く
  • この際自分以外の PR も存在する事を考慮する。代わりに引用するタイトルと、機能追加なのかバグ修正なのかを書けると良い
• もし PR のブランチが fix なら「[Fix] ほげほげ」、feature なら「[New] ふがふが」という行を生成。内容は以下のようになる

v1.0:
* [New] すごい新機能を追加
* [New] イケててヤバい新機能を追加
* [Fix] マジヤバいバグを修正

• 生成した内容を Vim の help (doc/caw.txt) に挿入して bot に PR を出してもらう
  • 良ければマージする
  • 悪ければ bot のコードを修正して再度生成させる (スパルタン方式)、もしくは派生PRで手動修正