Your own authoritative repos
This scenario may not arise if you are working on a fork of someone else’s repo. However, you may want to create your own repos and be the authoritative owner.
In this case, there are two ways people can collaborate
- Other people can fork your repo as described in the previous sections. This is the recommended approach when collaborating with other people you don’t know well.
- You can invite other GitHub users to work directly on your repo, without the need to fork. This is a faster, simpler way of doing things. However, it is important that a) you know and trust those users and b) that you make sure they use Git branches.
If the second option applies, then they create their Codio project directly from your repo as described on the previous page. However, when they try to push back to the repo, they will get an error as they do not have permissions to push directly into your repo.
The good news is that you can allow this by applying the necessary permissions in GitHub.
- Go to the repo in your GitHub account.
- Click the settings button near the top of the page.
- Press the Collaborators link on th left side.
- Add collaborators. You will need to know their GitHub name but can also search.
Regardless of whether you are the owner or any other collaborator. You should regularly pull in changes from the remote repo. There might not be any but the general approach is to pull often. This way you reduce the likelihood of lots of conflicts to deal with in one go.
git pull origin masteris the usual command but can vary if you are using branches.
It is very much recommended practice to use branches when collaborating. Branches are very powerful and allow you to develop anything you want in a safe way.
It is beyond the scope of this documentation to cover branches. However, once you are comfortable with the basics of Git, it is strongly recommended that you use and are comfortable with branches. You will really enjoy using them and they allow you to perform and even push any form of experiment without a) running the risk of messing up the master branch or b) creating another repo to experiment in.