It is critical to work together to discuss, to implement, and to review the development collaboratively in code level.

For git based development, we have two ways of collaboration:

  • One Shared Repository
  • Forked + Pull/Merge Request

The former one is the simplest form. The repository owner grants access to team members, and everyone works directly on this repository. Once you push something, it is something, and everyone should pull your work.

The latter one is a bit complex, but more suitable for team working. Let’s assume your repository is hosted on GitLab/GitHub/Bitbucket/etc. In this case, team members fork the main repository(a.k.a upstream repo) into their own platform account. They work on their forked version of the upstream repo. When something is done, they push to their forked repo, then they issue a pull/merge request to the upstream repo. The administrators of upstream repo can review the changes, discuss with the members, and finally accept/reject the request to merge the changes into upstream repo. This approach provides more flexibility to the coding collaboration.

The following are several short tutorials for each topic.

One Shared Repository Way

You may refer, Git - To Use Git More Easily: Config, Branch and Rebase. This article is created by Weigao Chen, a member of our Wireless Sensing Team.

Forked + Pull/Merge Request Way

There are 4 steps in this approach:

  • Fork the upstream repo
  • contribute code to your forked repo
  • Issue Pull/Merge Request
  • Keep the forked repo up-to-date

The following are tutorials for GitLab.com platform.

Fork

Refer to How to Fork a Project

Contribute to Forked Repo

Refer to Git - To Use Git More Easily: Config, Branch and Rebase

Issue Pull/Merge Request

Refer to How to Create a Merge Request

Keep Your Fork Up-To-Date with Upstream

Refer to Keep Your Fork Up-To-Date with Upstream