GitHub more than detailed tutorial team collaboration

This article will describe in detail how to divide the scene more than the team through GitHub collaborative development

Below an example a duo team (A team leader and team B), more than other players, then the team with the operations team B

A leader in the warehouse as a reference, the first warehouse structure B Fork project team captain A warehouse, the team captain A and B as follows:

队长 A：

 ┌── master ：最终的可上线版本分支
 │
 └── dev ：队长 A 本人开发分支

队员 B：

 ┌── master ：队员 B 经过开发、具有一部分新功能的分支，用于向队长 A 提出 PR
 │
 └── dev ：队员 B 本人开发分支 

Wherein, Master branch captain A is a well-tested, ultimately deployed version on the branch line, Master branch members B of its own after the development, completion of a sub-function or sub-modules, and after a simple test for the captain A branch proposed PR (Pull Resquest) of

Team member responsibilities are as follows:

• Captain A: In addition to assign development tasks, responsible for the development work, the more important task is to check the results of the development team members, resolve errors when the merger is completed on the project lines
• Team B: mainly responsible for the development

Warehouse is assumed that the initial state:

队长 A（主仓）：

 ── master ── project.txt（内容为 "module 1"）

队员 B（Fork 主仓）：

 ── master ── project.txt（内容为 "module 1"）

Scene One: the players and the main warehouse in sync version

A captain is assumed that after a merger, a submodule added on-line version and the items 2, the cartridge case main content:

── master ── project.txt（内容为 "module 1, module 2"）

A captain is due to the warehouse of the main warehouse, so players in the development of new functions, must first pull the most current version in order to keep pace

Team B clone own remote repository to local

git clone https://github.com/member_b/project.git

Add the primary remote warehouse warehouse address

git remote add upstream https://github.com/captain/project.git

View current Remote Warehouse Warehouse connected

git remote -v

At this point, the current remote warehouse warehouse connected to:

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)

Pulling the cartridge main file

git fetch upstream

Switch to the master branch

git checkout master

merge

git merge upstream/master

So far, the new version of the project file has been updated to the master branch, the next step you need to incorporate it into the dev branch for subsequent development on the dev branch

If you do not create a dev branch, create and switch

git checkout -b dev

merge

git merge master

B team members can work in a dev branch

Scene Two: the players and the main warehouse version merger

When a new team B is completed and tested module to push the master branch of the remote repository, the need to merge request made to the captain A, i.e. Pull Resquest

B players assume the project.txtadded "module 3"

B Pull Resquest new players in their GitHub repository, as

Selecting branch selected here made to PR dev cartridge main branch

After fill in the relevant information, click on "Create Pull Resquest" B team to complete the task

See Pull Resquest A captain in the main compartment, the Commitsdisplayed label B commit record player, Files changedfile content changes display tag

After checking the option to merge or after the rejection combining (i.e. Close PR)

Which, Merge Pull Resquest There are three options

• Create a merge commit : That this PR as a branch of the merger, and keep all records submitted on branch
• Squash and merge : That the merger reserved only for a commit record
• Rebase and merge : Find two common ancestor branch, and then merge all commit to a common ancestor from now on the current branch

Compared

• Create a merge commit : You can not keep the master branch clean, but retained all the commit history, when a large number of PR commit in this way is not recommended
• Squash and merge : You can also clean and maintain the master branch, but the author is a master maintainer, instead of the original author
• Rebase and merge : Master branch can be kept clean as possible, and easy to identify author

In this case, dev captain A branch on the new module added to the team B. With the merger while continuing to dev branch, until the completion of an on-line version, captain A can be dev branch into the master branch to deploy the line

Scene Three: When you merge conflicts

There are many conflict situations, such as B lazy players for several days did not work, and when he pulled the latest version of the file to the main compartment master branch, found that other teammates modify the content and for him to fix the bug, leading to team B in merger when conflict

For conflicts generated when the merge, you need to manually modify, eliminate conflicts

Warehouse state assumed as follows:

队长 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"）

When the team B fetch attempt to merge with the master, a conflict

Use VS Code View project.txt

=======Above is the current contents of the branch, the branch below is to merge incoming content. At this point, shall prevail main compartment version, you need to manually remove other content, or click on "using the incoming changes," amended as follows:

module 1, module 2.5, module 3

After, we also need

git add project.txt

git commit -m "fix conflict"

Then you eliminate the conflict, and then merged with the dev branch can be carried out follow-up work