２つの運用形態

僕は今本業でも副業でもGIthubを使ったチーム開発をしていますが、
Github上のリポジトリでチーム開発をする際、

の２つの運用ルールを経験しています。

本業も副業も企業のプロジェクトなのでもちろんプライベートなリポジトリです。
今回はそれぞれのルールにのメリット・デメリットについて書こうかなと思います。

1. フォークしたリポジトリからプルリクを出す

誰でも彼でもリポジトリにブランチを作成されては困るような、 OSS等の公開されたプロジェクトでよく取られる方法です。
hoge/fugaを user/fugaにフォークしてプルリクの向ける先を hoge/fuga:masterにする、という運用ですね。

これをプライベートリポジトリで運用する際について。

本家のリポジトリのブランチが増えない
ブランチを作成するのはフォークした先のリポジトリなので、
本家のリポジトリのブランチが増えません。
メンバーが管理できるブランチは自分のリポジトリ上のブランチだけで、
フォークしたリポジトリにブランチが増えてきたら適当に消しまくればいいだけです。ブランチ管理が楽です。
権限管理が楽
フォーク先のリポジトリは好き勝手やらせて、
本家のリポジトリではPR作成の最低限の権限だけで済みます。 force pushして本家リポジトリをぶっこわしたり、
めちゃくちゃな作業をされても本家はノーダメージでいることが出来ます。
メンバーがあまり信用できないとか（）、初心者が多いとか、そういった事情があれば強力かもしれません。

本家master追従が面倒
本家のmasterに追従するupstream等のブランチをつくっておき、
本家masterが更新されたら、フォークされたリポジトリのローカルのmasterにupstreamをマージしなければなりません。
これが結構手間です。
リポジトリを探すのが面倒
自分が関わるリポジトリが本家とフォーク先の2つになります。
フォーク先から本家へはリンクが表示されるので移動が簡単ですが、
本家のリポジトリのissue等を見ているときに、自分のフォーク先リポジトリを見ようと思うと、
検索するかブックマークから移動する等するしかなく、手間です。
他のメンバーのブランチに手を出せない
各フォーク先リポジトリのメンバーとして招待されていない場合(普通しない)、
他の人のリポジトリを手元にプルしたり出来ません。
微修正してあげる場合や、手元で動作確認する場合に非常に困ります。
特にそのプルリクがマージされる前提で作業をするというような見切り発車ができなくなります。

僕は面倒なのでこの運用が好きじゃありません。
面倒なだけならまだいいですが、他の人の作業ブランチに手を出せないことで、
チーム開発の効率が微妙に下がるのがかなりいただけないですね。

ちなみに、githubの無料ユーザー（プライベートリポジトリを作成できない）でも、
フォークしたプライベートリポジトリはプライベートになるので、
公開状態について心配する必要はありません。

プライベートリポジトリだとこちらのルールで運用されることが多いのではないでしょうか。

僕はこちらの方が楽で好きです。

他の人の作業ブランチに手を出せる
↑のデメリットで書いたようなことですが、
全てのブランチに手が出せるのでもちろん手元にプルして動作確認してみたり、
「ここ間違ってるから直しといたわ✌」ができます。
1リポジトリで完結するので楽
issue/PRみたりつくったり、ページ移動が少なくて済みます。

ブランチが増える
適当にブランチを作ったり、
マージ後に消すみたいな運用を忘れると、
途端に謎の消していいのかわからないブランチが増えます。運用で気をつけたり度胸のある人がどこかのタイミングで古いブランチを全消しすれば済む話ではあります。

↑本業で一番ブランチが浮いた状態で残っているリポジトリ
権限管理
適切に権限管理をする必要があります。
「この人は初心者であまりわかってなさそうだから最低限の権限で、この人は強いからマージ権限も与えて・・・・」とか管理が煩雑になります。まあ、 信頼の置けるチームなら全員に全権限をあげちゃえばいいとおもいます。

どちらも良し悪しありますが、forkする形式だと機能性が損なわれて、そうでない形式だと運用が面倒になる、という感じです。
僕はforkするの面倒だし嫌いですが、それぞれ好みがあるんでしょう（適当）