GitHubを用いた共同開発のフローに関しての質問です

Question

gitでのチーム開発を行うのですが、僕の中のイメージでは

1. ある程度の雛形を整えたレポジトリを共有,cloneで作業段階を統一

2. master から developブランチを切り、各自はdevelopからブランチを切ってローカルで作業

3. 各自は各自のブランチをgit push -u origin branch_1のようにしてリモートに各自のブランチを作る。以後pushでそこにcommitを追加する。

4. 各自の作業が一定まで行った段階で、branch_1からdevelopへpull requestを出す。

5. 管理者がレビューして認めたらマージする。

6. 開発者全員のブランチのdevelopへのマージが完了し、全体の作業を一区切りする段階でdevelopブランチをmasterにマージする。(このフェーズでは各自のブランチがない状態にする)

2~6を繰り返す。もし4でコンフリクトが発生していた場合、

• pull requestを出した人のローカルブランチ(branch_x)にリモートのdevelopをpull
• ローカルでコンフリクトを解消し、リモートのbranch_xにpush
• pull requestを出してマージ

と言う流れで考えているのですが、もっとこうした方が良い、これは間違いだ。などありましたら教えていただきたいです。

Answer 1

こんにちは。

基本的な流れはあっていると思います。質問通り、いくつか気になった点を指摘します。

3 において「各自のブランチ」と言っているのが気になります。
ブランチは「作業者」に紐付くものではなく、「タスク」に紐付くものです。各自がブランチを持つのは間違いないですが、それは各自にそれぞれの「タスク」が割り当てられているからであって、複数のタスクを割り当てていたらその分だけ (それ以上にも) ブランチを持っていても構わないのです。一人が開発以外に調査/検証や実験などを並行し、十数本の作業中ブランチを持つ瞬間もよく発生します。

6 についてですが、この運用の場合 master へのマージというのは開発フェーズで言うリリースに相当することになりますが、リリース時に「各自のブランチがない状態」にする必要はないはずです。
develop ブランチが全員の作業の集積となっているので、リリースを行う一通りのタスクが develop にマージされていることは前提ですが、その時「未来のリリースを目標とした開発中のタスク」が確実に存在しているはずです。
「リリースが完了するまで次期リリースへ向けたタスクを開始してはいけない」とするのは明らかに良い運用ではないと考えます。

Comments

[sho0423]

実務上の話が聞けて為になりました。ありがとうございます！確かにタスクごとにブランチを切ったほうがコンフリクトが生じにくそうですね。その為には個人が複数のブランチを受け持つのも理解できます。
masterへのマージがリリースに相当すると言う見識がなかったのでdevelopブランチで開発する重要性がよりわかりました。本当にありがとうございます！