GitHubでのグループ開発でコンフリクトを減らすには？

私自身はこれ系の話の経験は少ないのですが……

各作業者の作業領域というのがモジュール的な単位で分かれているならば「複数人が同時に編集するようなソースファイル」っていうのは言うほど数が無いんじゃないかな，と．

なぜならば，「担当モジュールの内側」の変更であれば他人と被ることは有り得ないわけなので，モジュール外に影響が及ぶのは「インタフェース仕様がかわっちゃいました」みたいな話が起きたときくらいなので．

で，そういう「外側に影響がある変更」が生じる際には，まぁ普通は「ここ，こういうふうに変えたいんだけど，大丈夫かな？」的な 話し合い/すり合わせ/etc が生じるでしょうから，マージ時になってコンフリクトになったとしても「なにこれイミワカンネー」とはそうそうならないと思うのです．
（なったとしても，ひとりでマージ作業をしなければ良いのではないでしょうか．「大学の授業で～」という話なら，物理的にメンバーに接触できるのでしょうし．）

まぁ，後は，いかにも厄介な箇所に手を入れるような場合には
「ちょっと今からここを修正したいから，この範囲に手を入れるのは待ってほしいかな．だいたい１時間くらい．で，終わったら言うからそしたらその修正を取り込んでくれ．」
みたいなのをしたって良いわけで．

個人的な回答になりますが、コンフリクトは起こる時は起こる。という認識を持っています。
もちろん、コンフリクト自体を起こさないようにするためには、ディレクトリ構造などを機能毎に切り分けたりして、１機能１人として担当を完全に分離することでチーム開発をしてもコンフリクトをある程度防ぐことは出来ます。

それでも、１つのシステムである以上、各機能をまとめている処理や、共通の処理などでコンフリクトは起こる可能性は大いにあります。

私もコンフリクト修正は苦手ですが、起きたらしょうがないと思い、内容が分からなかったら、担当やまとめている人に聞いて、デグレが起きないように気を付けています。

あと、これはおせっかいかもしれませんが、コンフリクトなどを通じて、他の人が書いたコードを読む訓練はしておいた方が後々の為になると思いますよ。

これからのＡＩ時代、コードを書く力よりも、コードを読んで理解する力の方が大事になってくると思うので。

致命的で破壊的なコンフリクト以外は、gitを使う上で正常なプロセスであると思っています。

質問者様の状況を見る限り、この致命的なコンフリクトが起こってしまったのではと思います。

そういった状況を避けるために私は普段

• 細かい粒度のプルリクエストとマージ

• チーム内でのコードレビュー文化

との二点を徹底しています。

コンフリクトはそもそも、複数人がファイルの同じ場所を触ってしまった際に現れるものですので、大規模の変更を加えたブランチをプルリクエストすると、当然コンフリクトの修正箇所も大規模なものになります。

そのため、機能ごとなど細かい粒度でのプルリクエストとマージが必要になります。

また、チーム内で優秀な人間がいるのであれば、その方が積極的にレビューをしていくことで、致命的なコンフリクト回避だけでなく、全体的なコードの質の上昇にもつながると考えています。

チームで開発を行うプログラマーとして、実際にプロジェクトでの流れをまとめてお伝えします。
長くなってすみません。

設計から開発のタイミングであれば、
開発担当者は担当する機能についてのソースファイルしか触らないので、コンフリクトは起こりません。
チーム内で共通して使用するものを作成する人もジャンルごとで分けて担当したりします。
例えばゲームであればキャラクターのステータスや行動などを定義した、キャラクタークラスファイルを実装する担当者が一人になるため、コンフリクトは起こりません。戦闘システムやクエストに関するクラスを作成する人は、キャラクタークラスを変更する必要が無いからです。
(ゲーム作成経験は無いので変な例えかもしれません、すみません)

開発から単体テストのタイミングでも、
単体テスト(多くの場合はおそらく自動テストのためのテストコード作成)はソースファイルに対してテストコードを書いたり、テスト用のデータを作成したりするのみなので、やはり他の機能との競合は起こらず、コンフリクトは起こりません。

問題が起こるとすれば、
例えば自分の実装担当機能Aを実現するために
「機能Bの関数でこういう値を返してくれたらやること少なくて済むのに…」
という感じで、設計にはない変更や機能追加を行った時くらいでしょうか。
あとは、共通使用している関数に勝手に分岐を入れて、特定の条件を満たすと既存とは別の結果を返すようになるとか。

いずれにしても、まずは設計段階である程度しっかり機能ごとの役割分担を決めておいて、
誰がどの機能を作るか、つまり誰がどのソースファイルを作るのかを明確にして、それ以外の人は基本的に触れない、というのが第一かなと思います。

共通使用する関数に変更を加えた場合は、最低限テストコードを実行して既存のテストがOKになることを確認する。
出来ればその呼び出し箇所を検索して、
「自分が変更したことでこれまでと違う動作にならないか」
は確認した方が良いと思います。
(一番は、その関数を使うメンバー全員に確認。面倒なら自分だけが使う関数として新規作成する)

いわゆるウォーターフォール的な開発の流れなので、これから主流になるやり方とはズレが出るかもしれませんが、
バイブコーディングなどでも基本的には
「役割ごとに機能を分割する」
「機能ごとに開発を行う」
「共通使用するものは安易に変えない」
という考え自体は普遍かなと思うので、参考になれば幸いです。