github プロジェクトをフォークすることと、github プロジェクトのブランチを作成することの利点と欠点について詳しく知りたいです。
フォークすると、元のプロジェクトの共同作業者リストに載る必要がなくなるため、プロジェクトの私のバージョンは元のバージョンからさらに分離されます。プロジェクトは社内で開発しているので、共同作業者として人を追加することに問題はありません。しかし、プロジェクトをフォークすると、変更をメイン プロジェクトにマージするのが難しくなるかどうかを理解したいと思っています。つまり、ブランチ化によって 2 つのプロジェクトの同期が維持しやすくなるのではないかと思います。言い換えると、ブランチ化を行うと、メイン プロジェクトの私のバージョンとメイン プロジェクトの間で変更をマージしてプッシュするのが簡単になりますか?
ベストアンサー1
特定のプロジェクトの共同作業者として登録されていないため、必ずしもブランチを作成したり、既存のブランチをプルしてそこにプッシュバックしたりできるとは限りません。
フォークはGitHub サーバー側でのクローン作成に過ぎません。
- 直接的に反撃する可能性がない
- とフォークキューマージリクエストを管理する機能が追加されました
フォークを元のプロジェクトと同期させるには、次の操作を行います。
- 元のプロジェクトをリモートとして追加する
- 元のプロジェクトから定期的に取得する
- そのフェッチから更新された関心のあるブランチの上に現在の開発をリベースします。
リベースを使用すると、変更が簡単であること（マージの競合を処理する必要がないこと）を確認できるため、元のプロジェクトのメンテナーにプロジェクトにパッチを含めてほしい場合に、プル リクエストがさらに簡単になります。
実際の目標は、直接参加が常に可能であるとは限らない場合でも、コラボレーションを可能にすることです。
GitHub 側でクローンを作成するということは、2 つの「中央」リポジトリ (「中央」とは複数の共同作業者から見えるという意味) が存在することを意味します。1つの
プロジェクトの共同作業者として直接追加できる場合は、フォークを使用して別のプロジェクトを管理する必要はありません。
マージのエクスペリエンスはほぼ同じですが、間接的なレベルが追加されます (最初にフォークをプッシュし、次にプルを要求します。元のリポジトリの進化により、高速フォワード マージが高速フォワードでなくなるリスクがあります)。
つまり、正しいワークフローはgit pull --rebase upstream(アップストリームからの新しいコミットの上に作業をリベースする)、次にgit push --force origin、独自のコミットが常に元の (アップストリーム) リポジトリからのコミットの上にくるように履歴を書き換えることです。
参照: