Chapter 8 Collaborating

To create a proxy for your collaborator, open a second terminal window. This window will represent your partner, working on another computer. In most real-world cases, the Owner needs to give the Collaborator access. On GitHub, click the settings button on the right, then select Collaborators, and enter their username.

Adding Collaborators on GitHub

To accept access to the Owner’s repo, the Collaborator needs to go to https://github.com/notifications, to accept access to the Owner’s repository.

In this case, you won’t need to give anyone access on GitHub, because both ‘partners’ are you.

Next, the Collaborator needs to download a copy of the Owner’s repository to their machine. This is called “cloning a repository”. To clone the Owner’s repository into your Desktop folder, the Collaborator enters in the second terminal:

> git clone git@github.com:KevinKotze/test_one.git "C:/Users/Kevin Kotze/Desktop/kev_test_one"

After Creating Clone of Repository

The Collaborator can now make a change in her clone of the Owner’s repository, in the same way as we’ve been doing before, where using the second terminal we add some additional text to our file:

> cd ~/Desktop/kev_test_one
> atom file_one.txt
> cat file_one.txt
# According to Arthur Samuel (1959), machine learning gives computers the ability to learn without being explicitly programmed.
# Today, this area of research largely considers the construction of algorithms that learn from and make predictions about the underlying data.
# It draws on the fields of statistics and functional analysis to derive a predictive function based on data.
# Machine learning algorithms are often categorized as being supervised or unsupervised.

To commit these changes, we go through the same steps:

> git add file_one.txt
> git commit -m "Add different forms of machine learning"
# [master e7619a2] Add different forms of machine learning
#  1 file changed, 1 insertion(+)

Then push the change to the Owner’s repository on GitHub:

> git push origin master
# Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.
# Counting objects: 3, done.
# Delta compression using up to 8 threads.
# Compressing objects: 100% (3/3), done.
# Writing objects: 100% (3/3), 407 bytes | 0 bytes/s, done.
# Total 3 (delta 1), reused 0 (delta 0)
# remote: Resolving deltas: 100% (1/1), completed with 1 local object.
# To github.com:KevinKotze/test_one.git
#    27c2e41..e7619a2  master -> master

Note that we didn’t have to create a remote called origin: Git uses this name by default when we clone a repository. This is why origin was a sensible choice earlier when we were setting up remotes by hand.

Take a look to the Owner’s repository on its GitHub website now (maybe you need to refresh your browser). You should be able to see the new commit made by the Collaborator.

To download the Collaborator’s changes from GitHub, the Owner now enters:

> git pull origin master
# Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.
# From github.com:KevinKotze/test_one
#  * branch            master     -> FETCH_HEAD
# Already up-to-date.
# ~\Documents\GitHub\test_one [master]> git pull origin master
# Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.
# remote: Counting objects: 3, done.
# remote: Compressing objects: 100% (2/2), done.
# remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
# Unpacking objects: 100% (3/3), done.
# From github.com:KevinKotze/test_one
#  * branch            master     -> FETCH_HEAD
#    27c2e41..e7619a2  master     -> origin/master
# Updating 27c2e41..e7619a2
# Fast-forward
#  file_one.txt | 1 +
#  1 file changed, 1 insertion(+)

Now the three repositories (Owner’s local, Collaborator’s local, and Owner’s on GitHub) are back in sync.

8.1 A Basic Collaborative Workflow

In practice, it is good to be sure that you have an updated version of the repository you are collaborating on, so you should git pull before making any changes to a document. The basic collaborative workflow would be:

  • update your local repo with git pull origin master,
  • make your changes and stage them with git add,
  • commit your changes with git commit -m, and
  • upload the changes to GitHub with git push origin master

It is better to make many commits with smaller changes rather than of one commit with massive changes: small commits are easier to read and review.

8.2 Fork a repository

If you want to propose a change to a repository, then you should fork it (rather than taking a clone of it).

To complete this task, go to the GitHub web browser and navigate to the repository of interest. In my case, I’m going to clone the package that is located at: https://github.com/cran/imfr. In the upper right hand corner, click Fork. This creates a copy of the repository in your GitHub account and takes you there in the browser. You can then use the above workflow to clone this personal version of the repository to your local machine.

This would allow you to make the changes locally, commit them and push them back to your fork. When/if you are ready to propose a change to the original code, you place a pull request from your fork on GitHub to the original repository of the original owner.

To get the new commits from the owner of the repository that you originally forked, you need to have more than one remote associated with your local repository. This is usually done in the Git Shell, although you can update your fork on GitHub browser. You will then be able to pull from the original Owner’s repository to get the commits into your local repository. For more on this see:

In the long run, you will want to learn how to configure a second remote for your local repository. Pull the new commits into your local repository, then push them to your own fork. For more on this see: