GitHub is a good platform for developers to collaborate and also store their work. One of the features provided is collaboration. This feature allows users to collaborate with other developers. Simply, you can share GitHub repository links with other developers. It is one of the best ways to work on the same project.
If you’re not familiar with this feature, you can follow this article to learn more about how to share GitHub Repository link with other developers. Before going through the steps, there are some important things you need to know about the GitHub collaboration feature.
Table of Content
Things You Should Know About GitHub Sharing Link
If your Git repository is only on your remote GitHub or GitLab account, it is not very useful. You need to pull or clone the code from the remote repo to your local machine so that you can work with the files and resources that are stored there. To do that, you need to find and use the GitHub URL.
Most of the time, all you need is the HTTPS-based GitHub URL to clone something. This one is the one that is shown by default on the page for the repository. But it comes in three different forms: HTTPS, SSL, and the GitHub CLI.
In this lesson, you’ll need to find a partner. The “Owner” will be one person, and the “Collaborator” will be the other. The goal is for the Collaborator to make changes to the repository owned by the Owner. In the end, we’ll switch roles, so both of us will be Owners and Collaborators.
1. The Owner has to give access to the Collaborator. Click the “Members” tab at the top of GitLab and type in the username of your partner.
2. The Collaborator must then get a copy of the Owner’s repository on her computer. We call this “cloning a repo.” The Collaborator enters:
$ git clone ssh://email@example.com:7999/vlad/planets.git ~/Desktop/vlad-planets
3. To get access to the Owner’s Repository, replace the vlad with the Owner’s username.
4. The Collaborator can now make modifications to her clone of the Owner’s repository in the same steps as before using the following commands:
$ cd ~/Desktop/vlad-planets
$ nano pluto.txt $ cat pluto.txt It is so a planet! $ git add pluto.txt $ git commit -m "Add notes about Pluto" 1 file changed, 1 insertion(+) create mode 100644 pluto.txt
5. Then, using GitLab, push the update to the Owner’s repository:
$ git push origin master Counting objects: 4, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 306 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://gitlab.cern.ch:7999/vlad/planets.git 9272da5..29aba7c master -> master
6. It’s worth noting that you didn’t need to construct a remote called origin: When we clone a repository, Git uses this name by default. (This is why, when we were manually configuring remotes, origin made sense.)
7. Check on the Owner’s repository on the GitLab website right now (maybe you need to refresh your browser.) You should be able to see the Collaborator’s new commit.
8. The Owner now enters the following command to download the Collaborator’s changes from GitLab:
$ git pull origin master remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From ssh://gitlab.cern.ch:7999/vlad/planets.git * branch master -> FETCH_HEAD Updating 9272da5..29aba7c Fast-forward pluto.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 pluto.txt
9. The three repositories are now in sync (Owner’s local, Collaborator’s local, and Owner’s on GitLab).
These are the easy steps on how to share the GitHub Repository link with other collaborators.
In practice, you should git pull before making changes to ensure that you have the most recent version of the repository with which you are cooperating. The fundamental collaborative workflow would be as follows:
- update your local repo with
git pull origin master
- make your changes and stage them with
- commit your changes with
git commit -m
- upload the changes to GitLab with
git push origin master
It is preferable to make several little changes rather than one large change in one commit.