新しいプロジェクトで git を使用するための 2 つの方法を検討しています。
開発者はパッチをメンテナー (おそらく最終的には開発者の 1 人になるでしょう) に送り、彼はそれらを適用し、テストして統合します
開発者はコミットを公開の「開発者」ブランチ (プロジェクトの各サブモジュールのブランチ) にプッシュし、メンテナーはプッシュに関するメール通知を受け取り、レビュー\テスト\統合できます。
最終結果は同じです - 開発者のコミットを含む最新のブランチに基づいています。
だから - 私の質問は、どちらが良いですか? 少人数のグループによる非オープン ソース プロジェクトの開発者で使用する必要がありますか? (私の隣に座っている男にメールでパッチを送るのは奇妙に思えます)
プル リクエストを送信して、代わりにそれらを処理してみませんか? それが、彼らが Linux カーネルで行うことです。
パブリック共有開発者ブランチの主な問題は、ブランチから不要なものを取得することです。公開された共有ブランチをリベースしたくないし、常に元に戻すのは面倒です。通常のパッチの主な問題は、SHA が同じパッチの送信者と受信者の間で一致しないことです (正当な理由により)。パッチメール システムを開発している場合、git-bundles を使用して正確な SHA を取得することを検討します。これはプルを行う複雑な方法であることに注意してください。
別のオプションは、gitolite を使用して (共有ブランチでのコミットを許可されているユーザーと許可されていないユーザーを強制するため)、開発者に「機能」ブランチで作業させることです ( http://nvie.com/posts/a-successful-git-branchingを参照)。 -model/および関連する gitflow コマンド) を使用し、信頼できる開発者のみがフィーチャー ブランチから dev/master ブランチへのマージを実行できるようにします。
また、gerrit やその他の git コード レビュー ワークフローを調べることもできます。
正しい方法はフォークです。つまり、開発者はリポジトリのクローンを作成し、自分の作業を行い、作業が完了したら、何らかの方法でプロジェクトのメンテナに連絡して、外国のリポジトリから新しいブランチをプルできるようにします。
Github は、UI で既にこれをサポートしています。