ちょっと稼動に余裕ができたので再読しつつメモを取ってみる。

branch の関係としては以下。

• master は maint の子孫
• next は master の子孫
• pu は next の子孫

開発の上流・下流で言うと逆になるとのこと。逆? とりあえず修正が盛り込まれるのは pu branch ということになるのかな。

以下な記述は一度試してみたい。

バグフィクスはそれを必要とする最も古いサポート対象のブランチにコミットします。そして(周期的に) その統合ブランチを上流の複数ブランチにそれぞれ merge します。

うーん、git-cherry-pick ですか。あるいは以下な記述もアレ。

master に適用されたバグフィクスが maint も必要としていることに気づいたとしたら

ええと、master は次期リリースに入るべきな歴史になるのですが、そこでバグが発見されて commit が作られてそれを安定版に反映させなければならない場合、master をそのまま merge したらアレ、という事なのか。

でも、このような自体はほとんど発生しないはず というあたりの意味を図りかねております。つーか逆に安定版な branch でバグフィクスな commit が作られる場合はどうなるんでしょ。

うー、これって試してみたい。maint に merge する必要があるバグフィクスはその安定版を作ったトピックブランチに修正を盛り込んで上に流してけば良いのだろうか。

つうことは上流に merge するためのトピックブランチは削除しては駄目なのかどうか。

もうひとつ

下流への merge のルール、がアレ。このあたりって複雑なプロジェクトを取り扱っていない、ということなのかどうか。

あと、「リリースにむけたブランチ管理」の項ではやっぱ maint で盛り込まれた修正は適宜 master に反映させなければ、みたいな記述がありますね。このあたり、原文も確認してみておく必要があるのかも。

ともあれ

基本的に公開リポジトリでは

• maint
• master
• next
• pu

という branch があれば良いのかどうか。某所では今二つでヤッてるのでとりあえず maint を作ってみる方向で考えてみたいと思います。

$ man gitworkflows

はもう少しきちんと原文チェックな方向で。