質問: **リモートリポジトリ** * Azure Dev Ops **gitクライアント** * SourceTree **開発人数** * 2~3 --- ブランチモデルのGit Flowを参考にして開発を進める場合、 1. developブランチをpull 2. pullしたdevelopブランチからfeatureにブランチを切る 3. featureブランチで作業をする 4. featureブランチでコミットし続け、作業が終わったらプッシュ 5. feature->developにプルリクエスト 6. マージ という感じになると思います。 朝に全員がdevelopブランチをプルし、夜に全員の作業が終わり、全員がそれぞれのfeatureブランチをプッシュしてプルリクを作成します。 ただ、マージする際にそれぞれのブランチで同じファイル(シーンなど)を編集していた場合、コンフリクトしてマージできないと思います。 なのでコンフリクトを起こしたら、コンフリクトするブランチでいったんリモートのdevelopをプルして(この時UnityYAMLMergeとか使う)再度プッシュし、マージするというのを繰り返すことになると思うのですが、あっているでしょうか。 複数人でgit運用したことがないので、これが普通なのであれば仕方ないですが、やり方が違うよ!もっといい方法あるよ!というのがあれば、ぜひとも教えていただけないでしょうか。 よろしくお願いします。
回答: こんにちは。 developからfeatureを分岐して最終的にdevelopにマージする、というのはおおよそ正しいですが、 「朝に全員が」「夜に全員の作業が」っていう発言がものすごく引っかかります。 gitのブランチ概念は「作業時間」に関係するものでは一切なく、featureブランチはその名の通り「feature(機能)」の単位です。 developから分岐した一つのfeatureは、そのブランチが担当する「機能」が「完成したときに」、developにマージされます。developブランチの中身は、機能が中途半端な状態にはなっていない、常に「基本的には動く」という状態になっているのが一般的です。 マージする際にコンフリクトを起こしていたら解消する、というのは正しいですが、UnityYAMLMergeと発言しているので、おそらくちゃんとマージの意味は理解しているだろうと思います。 もしかしてですが、featureブランチに「作業者の名前」などを付けていませんか?ブランチ名には「そのブランチが担当する(実装する)機能の名前」を付けてみると良いです。そうすれば、「朝・夜」などの発言が出ることはなく、その機能がある程度「実装完了した」というところでマージされるのが自然であることが理解できると思います。 1つのブランチが役目を終えるまでに1週間かかることもあれば、場合によっては、1日に3つや4つのfeatureブランチを作ってはすぐマージ、という作業者が居ても全くおかしくないのです。