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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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