回答:
私は、2つの主なシナリオで使用される開発者ブランチを見てきました。
これらのブランチは実際にはリポジトリフォークであるため、プロジェクトメンテナはマスターリポジトリへのアクセスをロックダウンでき、プルリクエストによる統合が必要になります。これにより、貢献者の生活はより困難になりますが、メンテナーの方がはるかに楽になります。もちろんこれはまさにポイントであり、GitHubで非常に成功したモデルです。
継続的な統合および展開の不安定性、さらに悪いことにビルドの不安定性の実績がないチームおよび組織。これらのチームは一般に、メインラインの安定性を保護する方法として開発者ブランチを使用しようとします。結果は、通常、リリース前の長くて非常に痛みのあるマージ期間に続き、さらに長くて痛みのある安定期間が続きます。リリース後まで発生しません。
これがCIを必要とする理由について暴言になりたくはありませんが、変更から十分な頻度で統合していないことがわかっていることはあなたの質問から明らかです。したがって、IMOは問題を回避する意味がありません。
外部の開発者からの変更を「ゲート」する必要がある地理的に分散したチームで実際に作業している場合を除き、開発者ごとのブランチモデルはあまり意味がありません。すべての開発者はすでに技術的に独自のリポジトリを持っているため、特にgitでは意味がありません。ほとんどの組織は、1日に数回、非常に頻繁に統合する必要があります。
私は現在、4つの別々のチームに分かれた約35人の貢献者のグループの一員です。ほとんどの人は1日に少なくとも2〜3回、一部の人は10〜15回チェックインします。ビルドが壊れているのは珍しく、数分以上壊れたままになることは非常にまれです。Gitはマージを非常に簡単に処理するため、ほとんどの場合、リモート開発者ブランチは不要なオーバーヘッドです。プッシュする前に、プルし、ローカルでマージし、コミットテストを実行するだけで、簡単です。
マスターブランチの安定性を保護するために絶対に統合を延期する必要がある場合、実証済みの典型的なモデルは、Git分岐モデルの成功で説明されているように、開発ブランチとも呼ばれる不安定なブランチを使用することです。開発者が少なくとも1日に1回、このブランチ（正常に実行せずにビルドするだけでよい）に正常にマージできない場合、リビジョン管理の問題ではなく、品質/規律の問題があります。統合されていない開発者ブランチを使用してそれをカバーすると、問題が延期されるだけであり、そうすることで、最終的なマージが実際に必要以上に苦痛で不安定になります。
機能ブランチは最悪ではありませんが、IMOが実際にそれらを保証するのに十分なほど大きいプロジェクトはほとんどありません。プロジェクトが非常に大きい場合（つまり、多数の機能が同時に処理される場合）、ソース管理の問題を紙に書き出すよりも、プロジェクトを個別の自律コンポーネントに分割した方が良い結果が得られます。
必要に応じてこのアドバイスを無視できますが、多くのチームがそうしますが、上記の分岐モデルが非常に人気があり成功している理由の1つは、それに対してではなく継続的な統合で動作するように設計されていることです。
作業ブランチでは、次のようにします。
git commit -am "Committing changes before merge"
git merge master
他の開発者ブランチからマージすることもできます
git checkout dev-A
git merge dev-B
それは、masterの変更を開発ブランチにマージすることです。
git merge masterにありますが、チェックアウトされた機能ブランチでは私が探していたものです。おかげで
dev-Aとdev-Bが異なるプロジェクトの異なるブランチである場合、@ scaryrawrが答えたものが最適です。
しかし、dev-Aとdev-Bが実際にまったく同じコード（同じプロジェクト）である場合、代替案は両方がブランチの1つで機能することです。たとえば、「devWork」という名前のマスターオフブランチを作成します。devWorkをチェックアウトし、作業を行い、変更をコミットしてプッシュします。プッシュされた変更はマスターではなくdevWorkにあり、ブランチの他のユーザーはローカルでPULLを実行するだけでプッシュされた変更を取得できます。
その後、標準的な方法に従って、devWorkの作業をマスターなどに戻すことができます。