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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Git

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

GitHub

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

Q&A

解決済

2回答

5468閲覧

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

yohira0616

総合スコア255

Git

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

GitHub

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

3グッド

0クリップ

投稿2016/04/22 06:33

###前提・実現したいこと
git(github)でプルリクベースのソースコード管理を行っています。
主な手順としては以下のようになります
0. メインブランチはmaster(出荷専用),develop(開発メインブランチ)の二種類

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

###発生している問題

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

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

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

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

KiyoshiMotoki, CodeLab, ikuwow👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

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

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

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

投稿2016/04/22 07:28

CodeLab

総合スコア1939

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yohira0616

2016/04/25 02:09

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

0

ベストアンサー

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

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

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

投稿2016/04/22 07:27

m_orishi

総合スコア68

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yohira0616

2016/04/25 02:12

「トピックブランチから更にトピックブランチを切る」という運用方法を知らなかったので使わせていただきます!ありがとうございます。 Rebaseは使い方がよくわからなかったので使っていなかったのですが、ちょっと調べて試してみます。ありがとうございます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問