/var/log/messages

debugging with sixth sense

git.git の Workflow

以下なエントリを発見。かなりいまさらでお恥ずかしい限りですが。

備忘まで、確認しつつメモを控えておくことに。

git.git では以下の統合 branch を使っているとのこと。

  • maint
  • master
  • next
  • pu

これ、採用したいな。maint と master というあたりが微妙ですが、これはリリースマネジメントの問題ですね。基本的には

  • master でリリースな tag を打って歴史をすすめる。Linux だと 3.x なバージョン番号?
  • maint も同様。Linux だと 3.x.x なバージョン番号にあたるのかどうか

む、これって試してみたいのですが、next な branch に居るある commit を cherry-pick で上流に適用すると branch 全体を merge する時にはスルーされるのかな。されそうなカンジ。

むむ

以下な記述があります。

統合ブランチを “習慣的に”(大した理由なく定期的に) トピックに merge する (話を広げて、定期的に上流を下流に merge する) ことには賛成できない、という点を指摘しておくべきしょう

これって topic branch が巨大というか長く続く、みたいな形だとありがちになりそうな気がします。つうかこれやっちゃうと駄目なカンジが第六感てきにアレですが (何

使いステ統合 branch

よく作ってますw これは正に git の利点じゃないスかね。

つうか

やはりこれは凄く良質なドキュメントですね。今携わってるソレに順次適用の方向。

あと、man gitworkflows ってしてみるに普通に端末で出力されました。これは必読ですね。

分散ワークフロー

git.git においてはサブシステムのメンテナたちだけが mergeワークフローを使っており、他の人たちは皆patchを送っています。

てやっぱ patch なのか。ぼくは実は PR よりこっちの方が分かりやすい人だったりするのですが。とは言え、PR でもなくてメイルでもない何らかの手法が見出されるべきなんだろうな、という事は痛切に感じている次第です。

もうちょい

maint と master の関係が分かってなかったのですが

$ git log master..maint

で commit が出てきたら maint を master に merge しなさい、と出てました。つーことは maint に何らかの変更が発生したら master に merge されているべきなのだな。 また、master と maint の関係として

$ git checkout maint
$ git merge --ff-only master

で merge が失敗しないこと、が前提になってる模様。

このあたり、現行なプロジェクトでどこまで適用できるのか、は確認する必要があるな。

Comments