私はまだバージョン管理とGithub全体に不慣れです。何かが私を非常に混乱させ、頭を包み込むことができないようです。2 人の男が同じ Rails アプリ プロジェクトに取り組んでいるシナリオを想像してみてください。Guy A はマスター レポを持っており、Guy B はレポをフォークした人です。ガイ B は、アプリには存在しなかった新しい機能を作成します。その際、希望する結果を得るためにいくつかのファイルを編集し、場合によっては移動する必要がありました。
一方、Guy A は非常に類似した機能に取り組んでおり、非常に類似したファイルを編集および移動する必要がありますが、ソース コードは非常に異なっています。あるいは、同じファイルを別のソース コードで編集する別の機能に取り組んでいるのかもしれません。次に、ガイ B がプル リクエストを送信し、ガイ A も彼が作成した機能をマスター ブランチにマージする必要があります。github は、2 人の異なる人物によって異なる方法で変更されたこれらの同じファイルをどのように調整しますか?
マルチユーザープロジェクトで作業した場合、ワークフローは次のようになります。
GuyAがローカルリポジトリに変更を加える->リモートリポジトリに変更をプッシュする
GuyBがローカルリポジトリに変更を加える->リモートリポジトリに変更をプッシュする（ここでは失敗します）
Guy Bは、git fetchその後にgit mergeまたはをgit rebase実行して、彼の変更がリモートからの変更とマージされるようにします。Guy Bは、これらの変更をすぐにリモートにプッシュする必要があります
Guy Aは、ローカルリポジトリでさらにいくつかの変更を行います->変更をプッシュします（再び失敗します）。彼は、マージまたはリベースに関して、GuyBと同様の一連の手順に従います。
また、Githubの用語で言えば、リモートリポジトリに変更をプッシュするという概念はpull requestgithubで処理されます。誰かがプルリクエストをリポジトリ内のブランチに送信する場合、このターゲットに対して変更のマージ/リベースを実行してから、を送信するのはリクエスターの責任pull requestです。
プルリクエストを受け取ったユーザーが、リクエスターがマージを行うのに十分な苦労をしなかったため、または以前に処理しなければならなかったプルリクエストがあったために多くの競合が発生した場合、所有者は質問できます。リクエpull requestスターは、最新の変更に加えて更新を送信します。
言い換えれば、プルリクエストを受け取った人は通常、受け入れるだけで満足しますがfast-forward merges、マイナーな例外はほとんどありません。
Github はプル リクエストにマージを使用します。場合によっては、プル リクエストのマージでは処理できない競合を解決するために、Guy B のリポジトリで手動のマージを行う必要があります。リベースが少しうまくいく場合もありますが、マイレージは異なる場合があります。
個人的には、自分のコードを最後に追加した人が、マージ/リベースを担当してから、プル リクエストまたは手動統合のいずれかを介して、権限のあるリポジトリまたはブランチにプッシュ バックするというのが私の方法です。