プライベートGithubリポジトリの共同編集者はそれぞれリポジトリをフォークする必要がありますか？
私は現在プロジェクトに取り組んでおり、ソースコードはGithubのプライベートリポジトリにあり、それぞれが共同作業者です。
はっきりしないのは、各作業をどのように分離するかです。
私たちがする必要があると私が思うことは：
- 私たち一人一人がリポジトリをフォークする必要があります
- コードをプッシュする準備ができたら、プルリクエストをプロジェクトリーダーのレポに送信します。レポは、これをコードレビューの機会として使用できます。
プライベートリポジトリに関して言えば、これはforkが使用されることになっているのでしょうか、それとも状況が複雑すぎますか？
リポジトリを開発者のローカルマシンに複製することは、すでに一種の分岐です。各開発者がGitHubのリポジトリをフォークした場合、これは現在の作業状態を公開するためだけに役立ちます。
これは、中央にマスターリポジトリがあり、そのリポジトリへの直接アクセスで信頼されていない多くの寄稿者がいる場合に適しています。これは、誰もがプルリクエストを投稿および発行できるオープンソースプロジェクトに最適で、コアメンテナのグループによってレビューおよびマージされます。複数のリポジトリを使用すると、プルリクエストベースのワークフローが適用されます。
小さな信頼できるチームでは、これは必要ありません。さまざまな人々が互いに干渉し合うのを防ぐために、Git Flowなどの戦略に従うことができます。それぞれの小さな機能は、個別の機能ブランチに実装されます。機能が完了すると、マスターブランチにマージされます。ほとんどのチームは、これをプルリクエストまたはコードレビューと慣例的に組み合わせますが、必要に応じてそれをスキップするのに十分信頼されています。個別のリポジトリは、開発者がフォークされたチーム可視のリポジトリの現在の状態を公開するのに対し、単一の共通リポジトリでは、変更を個別の機能ブランチにプッシュします。ほとんどのワークフローでは、マスター/トランクですべての開発を行うことはお勧めしません。
違いは結局のところ、アクセス管理のみに関するものであり、実装されたワークフローに関するものではありません。どちらの設定でも、プルリクエストベースのワークフローを実行できます。生のGitの観点から見ると、フォークとブランチの間に大きな違いはありません。どちらのアプローチも基本的にプロジェクトの履歴を共有し、他のブランチ/フォークに影響を与えることなくコミットを追加できます。これを考慮すると、信頼されたクローズドグループの場合は、単一のリポジトリを共有する方がはるかに良いでしょう。
これは機能しますが、各コントリビューに独自のブランチがあり、チームが同意するとマスターにマージされるブランチ方法を使用することもできます。