githubプロジェクトの分岐とgithubプロジェクトのブランチの作成の利点と欠点についてもっと知りたいのですが。
元のプロジェクトの共同編集者リストに登録する必要がないため、フォークを使用すると、プロジェクトのバージョンが元のバージョンから分離されます。プロジェクトは社内で開発しているので、人をコラボレーターとして追加しても問題ありません。ただし、プロジェクトをフォークすると、マージ変更をメインプロジェクトに戻すのが難しくなるかどうかを理解したいと思います。つまり、分岐によって2つのプロジェクトの同期を維持しやすくなるのではないかと思います。つまり、メインプロジェクトのバージョンとメインプロジェクトの間で分岐を行ったときに、変更をマージしてプッシュする方が簡単ですか。
回答:
特定のプロジェクトのコラボレーターとして登録されていないため、常にブランチを作成したり、既存のブランチをプルしてプッシュしたりすることはできません。
フォークは、GitHubサーバー側のクローンにすぎません。
次の方法で、フォークを元のプロジェクトと同期させます。
リベースにより、変更が単純であること（マージの競合が処理されないこと）を確認できるため、元のプロジェクトのメンテナーにパッチをプロジェクトに含めたい場合に、プルリクエストをより簡単に行うことができます。
直接参加が常に可能であるとは限らない場合でも、目標は本当にコラボレーションを可能にすることです。
GitHub側でクローンを作成するという事実は、2つの「中央」リポジトリ（「中央」は「複数の共同編集者から見える」として見える）を持っていることを意味します。1つのプロジェクトの
共同作業者として直接追加できる場合、別のプロジェクトを管理する必要はありません。フォーク付きのもの。
マージエクスペリエンスはほぼ同じですが、追加のレベルの間接性があります（最初にフォークを押してからプルを要求します。元のリポジトリが進化して、早送りマージが早送りされなくなるリスクがあります）。 。
つまり、正しいワークフローはgit pull --rebase upstream（アップストリームからの新しいコミットに基づいて作業をリベースする）であり、次にgit push --force origin、独自のコミットが常に元の（アップストリーム）リポジトリからのコミットの上にあるように履歴を書き換えるためです。 。
以下も参照してください。
高レベルの違いは次のとおりです。
writeリポジトリに対する権限を持っていない人。
それはGitの一般的なワークフローと関係があります。メインプロジェクトのリポジトリに直接プッシュすることはできません。GitHubプロジェクトのリポジトリがブランチベースのアクセス制御をサポートしているかどうかはわかりません。たとえば、マスターブランチにプッシュする権限を誰にも付与したくないからです。
一般的なパターンは次のとおりです。
これがなければ、公共プロジェクトがだれでも自分のコミットを直接プッシュできるようにするのは非常に珍しいことです。
Forkingは既存のリポジトリから完全に新しいリポジトリを作成します（単にgitHub / bitbucketでgit cloneを実行します）
フォークは最もよく使用されます。「分割」の目的が論理的に独立したプロジェクトを作成することであり、親と再会することは決してない場合があります。
ブランチ戦略は、既存/作業リポジトリ上に新しいブランチを作成します
ブランチは最もよく使用されます。ブランチを原点とマージすることを目的として、フィーチャを処理する一時的な場所として作成される場合。
より具体的に：- オープンソースプロジェクトでは、誰がリポジトリにプッシュできるかを決定するのはリポジトリの所有者です。ただし、オープンソースの考え方は、誰でもプロジェクトに貢献できるということです。
この問題はフォークによって解決されます。開発者がオープンソースプロジェクトの何かを変更したいときはいつでも、公式リポジトリを直接複製しません。代わりに、彼らはそれをフォークしてコピーを作成します。作業が完了すると、リポジトリの所有者が変更を確認し、変更をプロジェクトにマージするかどうかを決定できるように、プルリクエストを作成します。
コアの分岐は機能分岐に似ていますが、分岐を作成する代わりにリポジトリの分岐が作成され、マージ要求を実行する代わりにプル要求を作成します。
以下のリンクは、十分に説明された方法で違いを提供します。
https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/