knowledge-kitchen / course-notes

Getting and Submitting Your Work

All coursework in this course - assignments, exercises, projects, and exams - is given to you as a repository on GitHub. A repository, often shortened to “repo”, is simply an archive of files that keeps a record of every change ever made to them.

The same process applies to all coursework. There are three steps: make your own copy of the repository, do the work and upload it, and tell us where to find it.

Make your own copy

Every assignment starts from a repository that we have prepared. You do not work in our copy, since you do not have permission to change it. Instead you make a copy of it in your own GitHub account. On GitHub, such a copy is called a fork.

  1. Open the link to the repository given to you by the instructor.
  2. Click the Fork button towards the top-right of the page.
  3. Accept the settings you are shown and confirm. GitHub will make the copy in your own account. This takes a few seconds.
  4. You will then be looking at your own fork. Notice that its web address now includes your own GitHub username, where before it included ours. Copy that address, since you will need it twice more.

Do the work and upload it

Your fork lives on the GitHub website. To work on it, you need a copy of it on your own computer as well. Making that copy is called cloning, and sending your finished work back up to GitHub afterwards is called pushing.

  1. Clone your fork onto your own computer. In Visual Studio Code, click the Source Control icon in the left toolbar, click the button to “Clone Repository”, and paste in the address of your own fork. Take care to paste the address of your fork rather than our original, since you cannot make changes to ours.
  2. Do the work described in the README.md file, or in whichever other instructions file the repository contains - some repositories keep their instructions in a file named instructions.md or similar instead.
  3. Upload your work using the stage, commit and push features of Visual Studio Code’s Source Control panel. Type a short note about what you have done into the Message field, commit it to record your changes, and then push to send them up to your fork on GitHub.

You may push as many times as you like before the deadline. Each push simply updates your fork on GitHub with your latest work.

Tell us where to find it

Uploading your work is not by itself a submission. There are hundreds of repositories in student accounts, and we have no way of knowing that yours exists unless you tell us.

Share the web address of your fork using the messaging app specified by your instructor, posting it wherever the instructor has directed you to submit work.

If you are for some reason unable to use the messaging app, email the address to the instructor instead. This is a fallback rather than the normal route, and work submitted this way takes longer to be graded.

Check that you have really submitted

It is worth taking a moment to prove to yourself that all of this worked, rather than assuming that it did.

  1. Visit your fork on the GitHub website in a web browser and confirm that the changes you made are visible there. If you can see your work only on your own computer, it was never pushed.
  2. Confirm that the address you posted opens the repository when clicked, and that it is your own fork rather than our original.
  3. Confirm that you posted it where the instructor directed you to submit work, and not somewhere else.

Resubmit as many times as you want

You can re-submit as many times as you want before the deadline. Make changes to the files on your own computer, then commit and push them as before. There is no need to post the address a second time, since it continues to point at your work as you update it.

Team projects

Team projects follow the same process, but the team does it once between them rather than each member doing it separately. There is one repository for the whole team, never one per person.

  1. One member of the team - decide among yourselves who - forks the instructor’s project repository. Only that one person forks it.
  2. That same member then gives the rest of the team access to the fork. In the repository’s Settings tab, under Collaborators and teams, add each teammate and the course admins by their GitHub usernames.
  3. Everyone else clones that one shared fork onto their own computer. Do not fork it again, and do not fork a teammate’s copy. Doing so would leave the team with several separate projects instead of the single shared one that the whole team contributes to.
  4. All work is done within that one shared repository.
  5. Share the address of the team’s repository using the messaging app specified by your instructor, posting it wherever the instructor has directed.

Pull requests in a team repository

A pull request is a request to merge work into a repository, which teammates can review and comment on before it is accepted.

Because your team’s repository is a fork of ours, GitHub assumes that any pull request you open is meant to contribute your work back to our original. It therefore sets the base repository of a new pull request to our repository rather than to your team’s.

When you open a pull request, look at the base repository dropdown menu towards the top of the page and change it back to your own team’s repository, then check that the branch shown next to it is your team’s main branch. If you do not, you will be asking the instructor to merge your work into the original assignment repository, and your teammates will not be able to review or merge it as they normally would.

Late work

The history of a repository on GitHub shows the date and time of every push, and this is what determines when work was submitted. Each course’s syllabus describes the late work policy that applies.