私は 5 人の開発者のチームでより大きなプロジェクトに取り組んでおり、Mercurial を VCS として使用しています。
私たちは皆、機能/修正をプッシュする準備ができていると判断するまでローカルで作業してコミットし、変更をマージしてプッシュする傾向があります。私は通常、他のほとんどの人と同じように、1 日に数回プッシュ (およびリモートとのマージ) を行います。
多くの場合、これは「マージ クラッタ」につながります。複数の開発者が変更セットをプル、マージ、プッシュします。結果の履歴はあまりきれいではなく、次のようになる場合もあります。
その混乱の中で特定の変更セットを分離したり、それがどのように/何がどのように影響したかを理解することさえできるとは思えません（少なくとも私はその見通しに身震いします）。
マージが必要な場合、上記の履歴は問題ないと思いますが、これらのマージのほとんどは、リベースによって (安全に) 回避できます。
実際の質問:
- VCS の履歴が上記のように表示されるのは「正常」ですか? そのような歴史は避けるべきですか？
- そのような歴史をどのように避けることができますか？
「回避」部分について: 私たちが取り組んでいるタスクは多少分離されているため (バックエンド、フロントエンド、Web)、それらをブランチに分割したり、場合によっては別々のリポジトリに分割したりすることもできます。ただし、プロジェクトは互いに完全に独立しているわけではないため、いくつかのリポジトリに分割すると、利益よりも苦痛が生じると思います。名前付きブランチの方がはるかに優れているかどうかはわかりません.3つ以上のブランチが常に存在するため、頻繁にトランクにマージする必要があります.
特に多くの変更セットが互いに完全に独立しているため、リベースはオプションのように思えますが、リベースするかどうかを決定する負担が開発者にかかります。競合が発生する可能性があり、最終的にはマージする必要があります。これにより、そもそもリベースしない人が出てくる可能性が高いため、現在の状態に戻りました。
今のところ、履歴をきれいに見せるための別のオプションは考えられません。今はあまり問題にならないかもしれませんが、開発者が突然 20 人になったらどうなるでしょうか。歴史が一つの大きな迷路だとしたら、その意味は何だ？何十もの交差がある場合、変更セットの影響を追跡するのは難しいと思います。