質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.48%

  • Git

    1363questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。

  • GitHub

    817questions

    GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。

[git]プルリク承認者がボトルネックになる

解決済

回答 2

投稿

  • 評価
  • クリップ 0
  • VIEW 1,180

yohira0616

score 237

前提・実現したいこと

git(github)でプルリクベースのソースコード管理を行っています。
主な手順としては以下のようになります

  1. メインブランチはmaster(出荷専用),develop(開発メインブランチ)の二種類
  2. Redmineなどのチケット管理ツールに対応したトピックブランチを切る
  3. トピックブランチで開発を行い、開発が終了したらdevelopに向かってプルリクを投げる
  4. プルリク承認者がソースコード・動作確認を行い、問題なければdevelopにマージする。
  5. そのdevelopブランチから新たにトピックブランチを切って開発(2.に戻る)

発生している問題

プルリク承認者が多忙等、プルリクが何らかの原因で確認(リジェクトも含む)されないと、4.の時点で開発が止まってしまう。

理想としては、1チケットのプルリクを投げた段階で非同期的に次のチケットの開発に着手したいです。(チケットの手戻りは適宜対応するとしても待機する意味は無い

試したこと

・1件目のプルリクを投げた時点で、ブランチを元のdevelopブランチに戻し、そこから2件目のトピックブランチを切り、2件目のチケットに着手する
→1件目のブランチがマージされた時点で、2件目の元developブランチと現在のdevelopブランチの状態が変わってしまい、無用な衝突が起こる場合がある。

衝突を極力回避しつつ開発速度が出るようにしたいのですが、何か良い方法はありますでしょうか。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

+1

世間一般で同意は得られないと思いますが、私個人の意見では
開発初期のコードが繁茂にアップされるようなフェイズでは、git-flowやGitHub Flowスタイルの開発方式は使わないほうが良いと思っています。
プルリク承認者の負担があまりにも多く、また、ソースコードの共有も遅れてしまうため、問題発見が遅れたり、開発が遅延してしまう、コンフリクトの多発などメリットよりデメリットのほうが大きいと思います。
よほど慎重に作業分担の割り振りや作業計画、仕様検討をしておかないと必ず破たんします。

経験上、多少乱暴でも、開発初期はサブバージョン的にどんどんソースを更新していったほうが問題が少ないと思います。(少人数の開発であれば・・・ですが)
ただ、一度完成して、メンテナンスフェイズであればgit-flowは非常に有用だと思います。

どうしてもgit-flowやGitHub Flowスタイルでということであれば、チケットの粒度を荒くしてみる、もしくはチケットに親子関係を付けて、複数の関連したチケットがすべて終わった段階でプルリクエストするなど、プルリクエストの回数を減らすしてみるのが良いかもしれません。
また、次の作業や、ほかの人の作業に関連するチケットは優先度をつけて早めにプルリク処理を行ってもらえるようにしてはいかがかと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/04/25 11:09

    ありがとうございます。
    スピード優先の時はあえてgit flowを使わない、という手法もあるのですね。

    今回の件はファーストリリース終えた後の継続開発なのでフロー自体を変えることは難しいと思いますが、新しくプロダクトを作る時の参考にさせていただきます。
    チケットの粒度を粗くする手法についてはすぐできそうなので試してみます。

    キャンセル

checkベストアンサー

0

非同期的に開発を進めていく以上、おそらく衝突は避けられません。
トピックブランチの粒度にもよりますが、

  • 前提となるPRがある場合(衝突が予め分かっている場合)は、トピックブランチから新たにトピックブランチを切って開発する。(※PRに前提PRがある事を明記する)
  • 上記でない場合には、developからトピックブランチを立ち上げ、PRを投げる前にコンフリクトを解消する。
  • PRを投げたあとにdevelopの状態が変わったのであれば都度解消する。

など衝突が発生する前提で作業を進めていくほうが無用なストレスは無いかと思います。
Rebaseして衝突を細かく解消していくと、衝突発生時のインパクトも減りますので癖付けておくと良いかもしれません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/04/25 11:12

    「トピックブランチから更にトピックブランチを切る」という運用方法を知らなかったので使わせていただきます!ありがとうございます。

    Rebaseは使い方がよくわからなかったので使っていなかったのですが、ちょっと調べて試してみます。ありがとうございます。

    キャンセル

関連した質問

同じタグがついた質問を見る

  • Git

    1363questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。

  • GitHub

    817questions

    GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。