はじめに
githubのコラボレーションには、
- チームメンバーでプロジェクトリポジトリを共有する
- 個々の開発者がプロジェクトリポジトリをforkする
の２つの方法があると思います。
OSSプロジェクトのような見知らぬ人とコラボレーションするプロジェクトの場合はfork一択ですが、社内で使うときや外注先との共同作業などのときはどうするのが良いのでしょうか？
リポジトリ共有の場合
- プロジェクトリポジトリ内にブランチが作られるので、マージ済みのブランチは定期的に削除するなどしないと、リポジトリのサイズが肥大する。
- 権限の管理ができない。基本的にプロジェクトリポジトリ内のすべてのブランチの権限がチームメンバーに与えられる。protected branchesに設定することもできるが、個々のブランチごとに設定する必要がある。protected branchesに設定すると、プルリクエストによる承認を必須にしたり、force pushなどのリスキーな変更を制限したりできる。
- 作業した変更を取り込むのに、プルリクエストを出さずにマージコマンドでマージできる。プルリクエストを使わない開発フローを好む人もいる。
- 他のチームメンバーと、ブランチ名の衝突の可能性がある。
- 他の開発者が何をやっているかわかりやすい。
- forkする方法に比べてチームに一体感が出る（と思う）。
forkする場合
- 作業した変更を取り込むのに、プルリクエストが必須。個々の開発者のforkリポジトリをremoteに設定してマージもできるが、やる人はあまりいないでしょう。
- プロジェクトリポジトリの更新を取り込むには、プロジェクトリポジトリをupstreamに設定して、upstreamからプロジェクトリポジトリの変更を取り込む必要がある。gitに慣れていないチームメンバーがいると、ネックになる場合も。https://help.github.com/articles/syncing-a-fork/
- forkの数が増えると、社内の人だとわかっていてもなんとなくうれしい。
- 開発者個人のアカウントにリポジトリが作成されので、自分の参加しているプロジェクトが把握しやすい。
- プルリクエストをマージする人以外、他の開発者が何をやっているかわかりづらい。
おわりに
こういうふうにそれぞれの特徴を挙げていくと、
リポジトリ共有では、他の開発者が何をしているかわかりやすい
と
forkでは、プロジェクトリポジトリの完全なコントロールができる
が重要なポイントで、どちらをより優先したいかプロジェクトごとに検討が必要だと思いました。他のポイントは、上の２つに比べると副次的な感じがしています。当たり前の結論になってしまいましたが、ポイントが整理できたので良かった、、のかな？