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.
Refer to How to Fork a Project
Contribute to Forked Repo
Issue Pull/Merge Request
Refer to How to Create a Merge Request