この記事では、GitHubの共同開発を通じてより多くのチームよりもシーンを分割する方法を詳細に説明します
たとえば、以下にさらに他の選手よりもデュオチーム（チームリーダーとチームB）、運用チームBと、その後のチーム
参照として倉庫のリーダーで、最初の倉庫構造BフォークプロジェクトチームキャプテンのA倉庫、チームキャプテンのAとBは次のよう：
队长 A：
┌── master ：最终的可上线版本分支
│
└── dev ：队长 A 本人开发分支
队员 B：
┌── master ：队员 B 经过开发、具有一部分新功能的分支，用于向队长 A 提出 PR
│
└── dev ：队员 B 本人开发分支
前記マスター分岐船長Aは分岐線に十分にテストされ、最終的に展開されたバージョンである、独自のマスター分岐部材B現像後、サブ機能またはサブモジュールの完了、及び船長Aのための単純な試験後ブランチは、提案されたPR（Resquestプル）の
次のようにチームメンバーの責任は以下のとおりです。
- キャプテンA：開発作業を担当するアサイン開発タスクに加えて、より重要なタスクがあり、開発チームのメンバーの結果を確認し、解決エラーの合併は、プロジェクトラインで完了し
- チームB：開発の主な原因
倉庫は、初期状態と想定されます。
队长 A（主仓）：
── master ── project.txt（内容为 "module 1"）
队员 B（Fork 主仓）：
── master ── project.txt（内容为 "module 1"）
シーンワン：同期バージョンのプレイヤーとメイン倉庫
船長は合併後、サブモジュールがオンラインバージョンとアイテム2、カートリッジケースメインコンテンツを追加しているものとします。
── master ── project.txt（内容为 "module 1, module 2"）
船長は、メインの倉庫の倉庫に起因しているので、新しい機能の開発に選手は、最初のペースを維持するために、最新バージョンを引く必要があります
チームBは、ローカルに自分のリモートリポジトリのクローンを作成しました
git clone https://github.com/member_b/project.git
主遠隔倉庫倉庫アドレスを追加します
git remote add upstream https://github.com/captain/project.git
現在のリモート倉庫倉庫を見る接続
git remote -v
この時点で、現在のリモート倉庫倉庫に接続されました：
origin https://github.com/member_b/project.git (fetch)
origin https://github.com/member_b/project.git (push)
upstream https://github.com/captain/project.git (fetch)
upstream https://github.com/captain/project.git (push)
カートリッジメインファイルを引っ張ります
git fetch upstream
masterブランチに切り替え
git checkout master
合併
git merge upstream/master
これまでのところ、プロジェクトファイルの新しいバージョンは、マスターブランチにあなたはdevの枝に、その後の開発のためのdevの枝にそれを反映させる必要があり、次のステップを更新されています
あなたはDEVブランチを作成しない場合、作成およびスイッチ
git checkout -b dev
合併
git merge master
Bチームのメンバーは、DEVブランチで作業することができます
シーン2：プレイヤーとメイン倉庫バージョン合併
新しいチームBが完了し、テストしたリモートリポジトリのmasterブランチをプッシュするモジュールを、船長Aに行われた要求をマージする必要がある、すなわちResquestを引いているとき
Bの選手が前提としproject.txt、「モジュール3」を追加します
GitHubのリポジトリにあるBプルResquest新しいプレーヤー、
PR DEVカートリッジメインブランチにここで選択なさ選択ブランチ
関連情報を入力した後、タスクを完了するために「プルを作成Resquest」Bチームをクリックしてください
メインコンパートメントにプルResquest Aのキャプテンを参照してください、Commits表示されたラベルBは、レコードプレーヤーをコミット、Files changedファイルの内容が表示タグを変更します
オプションをチェックした後マージしたりするために組み合わせる拒否した後（すなわち閉じるPR）
これは、マージプルResquest 3つのオプションがあります。
Create a merge commitこの合併の支店としてPRし、枝に提出されたすべてのレコードを保持することSquash and merge：合併はコミットレコードのためだけに予約ことRebase and merge：2つの共通の祖先の枝を見つけ、その後、現在のブランチ上で、今から共通の祖先にコミットするすべてのマージ
コントラスト
Create a merge commit：PRの多数は、このようにコミットするときには、推奨されていない、クリーンなマスターブランチを維持するが、すべてのコミットの歴史を保持することはできませんSquash and merge：あなたはきれいにすることもできますし、マスターブランチを維持するが、著者は、代わりに元の著者の、マスターメンテナでありますRebase and merge：マスターブランチはできるだけ清潔に保つことができ、かつ特定しやすい著者
この場合は、新しいモジュールのDEVキャプテンAブランチはチームBに追加します DEV分岐し続けながら合併して、オンラインバージョンが完了するまで、船長Aは、ラインを展開するために、マスターブランチにDEV分岐であることができます
シーン3：あなたは競合をマージ
そのようなB怠惰な選手として多くの紛争は、数日間がある仕事をしませんでした、と彼はメインコンパートメントマスターブランチへのファイルの最新バージョンを引っ張ったときに、他のチームメイトは、合併でチームBにつながる、彼はバグを修正するためのコンテンツとを変更することがわかりましたとき紛争
マージは、手動で変更する必要がある場合、競合が発生したために、競合を排除
次のように倉庫の状態が想定さ：
队长 A（主仓）：
┌── master ── project.txt（内容为 "module 1, module 2.5, module 3"）
│
└── dev ── project.txt（内容为 "module 1, module 2.5, module 3"）
队员 B（fetch upstream 前）：
┌── master ── project.txt（内容为 "module 1, module 2, module 3"）
│
└── dev ── project.txt（内容为 "module 1, module 2, module 3"）
チームBは、競合をマスターと合併しようとする試みを取得する場合
使用VSコードビュー project.txt
=======上記はブランチの現在の内容で、以下のブランチは、着信コンテンツをマージすることです。この時点で、メインコンパートメントのバージョンを優先するものは、手動で次のように改正され、「入ってくるの変更を使用して、」上の他のコンテンツを削除するか、をクリックする必要があります。
module 1, module 2.5, module 3
後、我々はまた、必要
git add project.txt
git commit -m "fix conflict"
そして、あなたは競合を排除し、その後、フォローアップ作業を行うことができるのdevの枝と合併しました
