プライベートGithubリポジトリの共同編集者は、それぞれリポジトリをフォークすべきですか？

私は現在プロジェクトに取り組んでおり、Githubのプライベートリポジトリにソースコードがあり、私たちはそれぞれ共同作業者です。

不明な点は、各作業を分離する方法です。

私たちがする必要があると思うことは：

1. リポジトリをフォークする必要があります
2. コードをプッシュする準備ができたら、プルリクエストをプロジェクトリーダーのレポジトリに送信します。レポジトリは、これを同時にコードレビューを行う機会として使用できます

プライベートリポジトリに関しては、これはフォークを使用することになっているのでしょうか、それとも状況を複雑にしすぎていますか？

リポジトリを開発者のローカルマシンに複製することは、すでに一種の分岐です。各開発者がGitHubでレポジトリをフォークした場合、これは現在の作業状態を公開するためだけに役立ちます。

これは、中央のマスターリポジトリと、そのリポジトリへの直接アクセスで信頼されていない多くの貢献者がいる場合に適切です。これは、誰でもプルリクエストを提供および発行できるオープンソースプロジェクトに最適で、プルリクエストはコアメンテナーのグループによってレビューおよびマージされます。複数のリポジトリを使用すると、プルリクエストベースのワークフローが強制されます。

小さく信頼できるチームでは、これは必要ありません。さまざまな人が互いに邪魔するのを防ぐために、Git Flowなどの戦略に従うことができます。小さな機能はそれぞれ、個別の機能ブランチに実装されます。機能が完了すると、masterブランチにマージされます。ほとんどのチームは、これをプルリクエストまたは慣例によりコードレビューと結び付けますが、適切な場合はそれをスキップするのに十分な信頼を得ています。別個のレポジトリは、開発者がフォークされているがチームに見えるレポジトリで現在の状態を公開するのに対して、単一の共通レポジトリでは、変更を別の機能ブランチにプッシュします。マスター/トランクですべての開発を行うことは、ほとんどのワークフローで非常に推奨されていません。

違いは、アクセス管理のみに関するものであり、実装されたワークフローに関するものではありません。どちらの設定でもプルリクエストベースのワークフローを実行できます。生のGitの観点から見ると、フォークとブランチの間に大きな違いはありません。どちらのアプローチも基本的にプロジェクトの履歴を共有し、他のブランチ/フォークに影響を与えずにコミットを追加できます。これを考慮すると、信頼できる閉じたグループにいる場合、単一のレポを共有する方がはるかに良いでしょう。

これは機能するか、各contribが独自のブランチを持ち、チームが同意したときにmasterとマージされるブランチ方法を使用できます。