チームメイトと私はソフトウェア ベンダーで働いており、クライアント向けに大規模なソフトウェアを構築しています。数十人の開発者が、ソース管理に Git を使用しています。4 つのリリースがあります。
- 0.9: 生産中
- 0.9.1: クライアントでテスト中
- 1.0: 私たち (ソフトウェア ベンダー) によってテストされています。
- 1.1: 構築中
私たちの現在の作業慣行は、たとえば 0.9.1 のバグを修正する場合、
- 最新の 0.9.1 をプルしてから、修正を 0.9.1 にプッシュします。
- 1.0 に切り替える、最新の 1.0 をプルする、0.9.1 をマージする、1.0 にプッシュする
- 1.1 に切り替える、最新の 1.1 をプルする、1.0 をマージする、1.1 にプッシュする
問題は、何十人もの開発者がいる場合、多くの場合、複数の人が同時に修正をプッシュしようとしていることです。その結果、多くの場合、人々は同じマージを行い、互いの変更をマージしています。例えば：
- dev1 は fix1 を 0.9.1 にプッシュし、1.0 をプルしてマージを開始します
- dev1 が 1.0 にマージしている間に、dev2 は fix2 を 0.9.1 にプッシュし、1.0 をプルして、自身の fix2 だけでなく fix1 もマージし始めます
- さらに、マージは 1.1 に対しても行う必要があります。
このすべての苦痛のために、人々はローカル マシンで (バックアップなしで) 多くのコミットを行い、その後、1 日に 1 回または数日に 1 回の大規模なマージを行う傾向があるのではないかと思います。
この問題は、他の大規模な Git ベースのプロジェクトでも発生すると思います。この問題にどのように対処したかについて、そのようなプロジェクトに取り組んだ人々から聞きたいです。