Working in a team rather than alone can allow you to build more advanced projects, but it can be a little tricky to divide up the work and make sure that no one is overwriting anyone else's code unintentionally. We have used Git to backup our work and save our changes as we go, but it is also a powerful tool for working in a group.
To determine the best workflow for team development, a few decisions have to be made regarding the roles of team members. On GitHub, developers contributing to the project can be owners, collaborators or contributors. In this lesson, we detail how a team member's role will determine the workflow for team development.
One of the first decisions a team will need to make is to determine who will own the GitHub remote repository. Every project should have one main repository that is created with a single GitHub account. If there is a logical owner or team leader for the project, it makes sense that the main repository is created with their account. If not, the team should determine who will create the main and therefore be the owner.
The owner will have the following privileges for the repository:
Once an owner is determined, other developers can work on the code as either collaborators or contributors.
Collaborators are members of the core development team and are officially designated as collaborators by the owner. When working in teams at Epicodus, team members are collaborators.
Collaborators have the following privileges for the repository:
They will use a [branching and merging] workflow when they add and modify code for the project.
To assign a person as a collaborator, the owner will need to follow these steps:
Go to the
Settings menu on the right side of the main repository (see in red box below).
Manage Access on the left side menu:
Invite Teams or People:
Select a team or member above to add the GitHub user to the project. At that point, the GitHub user will be sent a confirmation email. Once they have confirmed, they will be added to the project.
You may optionally update a user's role in the
Manage Access pane. If you want to be very careful about access, you'd give
Read access, which allows contributors to create and comment on issues and also create pull requests. For group projects, it's more likely that you will give
Write access will allow contributors to make direct changes to the repository, including pushing to the repository and managing issues.
Admin access allows additional functionality such as adding collaborators and updating repository settings.
Anyone can be a contributor on an open source repository. Contributors are interested developers that want to offer code but can NOT make commits directly to the main repository. The workflow of a contributor uses [forking and pulling] to submit their code for review (pull request) to the core development team. The core team can then determine whether to merge the code with the main or not.