前職で「projectブランチ」をよく使っていたが、知っている人が居なかったのでメモとして残す。

featureブランチによる運用

単独で作業をする場合、featureを作成して作業します。

ブランチの作成

featureは、developから切ります。

レビューとマージ

featureで作業が完了したら、developへのプルリクエストを作成してコードレビューの依頼を出します。

projectブランチによる運用（基本）

複数人で作業する場合、projectとfeatureを作成して作業します。

projectブランチの必要性

featureブランチを複数人で共有して作業すると、コンフリクトが発生しやすくなります。  
ローカルで作業し、pushしようとしたらコンフリクトが発生する場合もあり作業性が悪いので、  
「ひとつのブランチを複数人で直接共有する」のは避けたほうが良いです。

projectブランチは、複数人で直接共有しないために用意するので基本的にprojectブランチで作業することはありません。
（コンフリクト発生時には、解消のためにprojectブランチで作業が必要な場合もあります）

ブランチの作成

projectは、developから切ります。

featureは、projectから切ります。

レビューとマージ

featureで作業が完了したら、projectへのプルリクエストを作成してマージの依頼を出します。
（コードレビューは必須ではありません）
マージする人は作業者以外の人であれば誰でも構いません。

projectですべての作業が完了したら、developへのプルリクエストを作成してコードレビューの依頼を出します。

コンフリクトが発生した場合

コンフリクトが発生した場合は、projectでコンフリクトを解消する作業を行います。

projectブランチによる運用（応用）

projectから作成しているfeatureは、とくに縛りはありません。

featureはマージした後に使いまわしても、新しく作成しても問題ありません。