Github組織のリポジトリ、問題、複数の開発者、フォーキング-ワークフローのベストプラクティス
奇妙なタイトルです、そうですが、私がカバーするために少し根拠があります。
プライベートリポジトリを持つgithubに組織アカウントがあります。 githubのネイティブの問題/プルリクエスト機能を使用したいと思います（プルリクエストは基本的に正確にコードレビューと機能のディスカッションで必要なものです）。 hub by defunkt というツールが見つかりました。これは、既存の課題をプルリクエストに変換し、現在のブランチを自動的に関連付けることができるというクールな小さな機能を備えています。
組織の各開発者が組織のリポジトリをフォークして機能の作業やバグの修正などを行うのがベストプラクティスかどうか疑問に思っています。これはかなり確かなワークフローのようです（github上のオープンソースプロジェクトごとごとに基本的にそうです）ですが、問題を追跡し、ONEからのリクエストをプルできることを確認したいと思います。ソース、組織のリポジトリ。
だから私はいくつかの質問があります：
- この場合、開発者ごとのフォークのアプローチは適切ですか？少しやり過ぎかもしれません。直接のプッシュアクセスがなく、すべてのコードを確認する必要がある開発者を紹介しない限り、すべての開発者にforkが必要かどうかはわかりません。そのような場合、そのような開発者だけのために、そのようなポリシーを制定したいと思います。それで、どちらが良いですか？すべての開発者が1つのリポジトリにいるのか、それともみんなのフォークなのか？
- ハブツール、特にプルリクエスト機能の経験がある人はいますか？開発者ごとにforkを実行する場合（または特権の少ない開発者の場合でも）、ハブのプルリクエスト機能は、上流のマスターリポジトリ（組織のリポジトリ？）からのプルリクエストで動作しますか、それとも動作が異なりますか？
[〜＃〜]編集[〜＃〜]
私は問題、フォーク、プルリクエストを使っていくつかのテストを行い、それを発見しました。組織のリポジトリに課題を作成する場合は、組織からリポジトリを独自のgithubアカウントにフォークし、変更を加えて、フォークのマスターブランチにマージします。 hub -i <issue #>を実行しようとすると、エラーUser is not authorized to modify the issueが発生します。だから、どうやらそのワークフローは機能しません。
この場合、開発者ごとのフォークのアプローチは適切ですか？少しやりすぎかもしれません。直接のプッシュアクセスがなく、すべてのコードを確認する必要がある開発者を紹介しない限り、すべての開発者にforkが必要かどうかはわかりません。そのような場合、そのような開発者だけのために、そのようなポリシーを制定したいと思います。それで、どちらが良いですか？すべての開発者が単一のリポジトリにいるのか、それともみんなのフォークなのか？
チームの規模次第ではないでしょうか。私は小さなチームで働いていましたが、リポジトリは1つだけで、機能にはそのリポジトリ内に独自のブランチがありました。これでうまくいきました。
しかし、私は現在、数十人が中央リポジトリにアクセスできる、より大きなオープンソースプロジェクトに定期的に貢献しています。バグ修正を直接プッシュすることはできますが、コードを確認できるように、個人用リポジトリですべての主要な開発を引き続き行い、機能のPRを送信します。メインのリポジトリはmasterとreleaseブランチのみを持ち、乱雑にならないようにします。機能ブランチは個人的なレポジトリにあるため、他のユーザーに表示される可能性があります（初期のPRを作成すると、機能の作業が進行中であることをチーム内の他のユーザーに警告します）。このワークフローは、少数の開発者以上のプロジェクトに推奨できます。唯一の欠点は、複数のリモコンを操作する必要があることです。
コードレビューとコード品質を重視する場合、fork-per-developerアプローチは非常に優れたアプローチです。プルリクエストを使用することの良い点は、責任をメンテナから開発者に移すことです。
開発者は自分のコードをmainブランチに入れたいので、それを含めるように要求します。
これは、人々がコミットする古いモデルとはかなり異なるコンテキストであり、後でレビュー担当者は「ああ、数週間前に行ったこの作業はあまりよくなかったので、今すぐ修正してください」と言わなければなりませんでした。
弊社ではこのモデルを使用しています。プルリクエストは、コードリクエストを実行可能にし、他の人々のコードについての議論を促し、新しいツールに最初に反対していた開発者であっても、一般にコード品質を助けました。また、レビュー担当者はコードが既にコミットされた後に単に「OK」または「OK」と言うのではなく、コードをメインブランチに積極的にマージする必要があるため、人々がコードレビューをより真剣に受け止めたようにも感じます。
私はすべての分岐と分岐をすべて行うわけではありません。これはgithub上のオープンソースgemに適したモデルですが、モデルは通常、変更についてより高いレベルの信頼を持っている組織内にあります。
ソース管理の主なポイントは、変更の確認、取り消し、取り消しなどができることです。あなたの状況で多数のフォークとブランチを行うことは、私見ではやりすぎです。
私はブランチを次のようなもののために予約します：バージョンのアップグレード、技術の一部の変更、メインベースとの共通点がほとんどない3か月間のサブモジュールの作業。
組織内ではまったくフォークしないかもしれません。このモードは、社内プロジェクトとは性質が異なるオープンソースプロジェクトに適しています。
私はあなたの焦点をテストとコードレビューに切り替えます。人々はテストを書いていますか？あの人達は良いですか？コードレビューは行われていますか？