読者です 読者をやめる 読者になる 読者になる

gitworkflowについての雑感

git mercurial

振られたので。詳しい内容はリンク先をどぞー。

git reset

特徴的というか、僕が「やっぱgitらしいなー」と思ったのは、git reset <branch>を積極的に利用している点です。 gitworkflowでは4種類の統合ブランチを用意していますが、そのうち2種類が使い捨てのブランチというのが面白いです。

  • maint - メンテナンスリリースはここから。時折masterへマージする。
  • master - 機能リリースはここから。
  • next - 使い捨て。機能リリース(masterからのリリース)後にgit reset --hard masterされる。
  • pu - 使い捨て。機能リリース(masterからのリリース)後にgit reset --hard masterされる。

git-flowgithub-flowはトピックブランチのresetやrebaseはあっても統合ブランチをreset、rebaseすることはありません。

マージ

マージの回数が多く、同じ変更をいろいろな統合ブランチにマージします。

  • バグ修正(基本的maintからトピックブランチを作成する)

    • nextにマージ
    • maintにマージ
  • 新機能(基本的masterからトピックブランチを作成する)

    • puにマージ
    • nextにマージ
    • masterにマージ

トピックブランチのマージはたくさん発生しますが、統合ブランチ間のマージはmaintmasterのマージのみ行われます。

  • maintの変更
    • masterにマージ

実験で汚れたpunextgit reset --hard masterできれいに掃除するのでマージは発生しません。

パッチ

うすうす感づいてると思いますが、gitworkflowはプルリクエストを利用するワークフローではありません。

githubのgitのミラーリポジトリの説明には「This is a publish-only repository and all pull requests are ignored」と注意書きがあります。変更を送りたい場合はSubmittingPatchesにある通り、メーリングリスト(git@vger.kernel.org)にパッチを投げることになっています。

gitといい、mercurialといい、みんなメールが好きですね。mercurialの方でよく聞かれる主張としては、誰も他人のプルリクエストを見ないし、検索しないので、知識の蓄積ができないというのがありました。gitの方はどんな理由なんでしょうね。(だれか詳しい人おねがいします。)

gitworkflowを使うべきか

前職の仕事でgitworkflowのブランチ運用を採用しようという提案があり、みんなで検討したのことがあるのですが、手間が多すぎるので安定trunkパターン(masterマイルストーンブランチ)にすることになりました(してもらいました)。

このときは、だいたい次のようなことを考えていました。

  • puにあがった変更の動作を確認する場所がない。
    • テスト環境にはnext相当のものがあがる。puはのせない。
      • 環境を用意するお金の問題も、、
  • リファクタリング、コードの整理はさっさとリリースしたい。何度もマージしたくない。
  • 変更点をnextにマージ後masterに個別にマージするうまみが少ない。
    • マージ漏れはgit logで発見できるが、ちまちまマージするのが面倒。
    • ほとんどの場合、全部マージする(or必要なものだけrevertする)方が簡単。
      • 要望や優先順位は会議で決まる。(あ、開発者も出席してるやつね)
      • 優先順位、マイルストーンで作業しているからやっぱリリースしない!があまり発生しなかった。
        • やっぱリリースしないものはだいたい出来てない機能なので、マージもされてない。
      • 先のやつはトピックブランチのままでもあまり困らない。
  • nextを検証環境で確認しても意味がない。
    • masternextの差が発生する場合はテスト環境にのせる意味がない
      • 同じものが本番にリリースされない不安がある
    • masterと差が発生しないならnextいらない(マイルストーンブランチをmasterにマージすればよいじゃん)

まとめると、nextpuの使い方が請負の仕事には合わなかったという話です。

なので、nextpuをうまく活用できるのであれば採用できますが、それ以外はさけた方がよいというのが僕の考えです。