Share on GitHub

What GitHub adds to Git

GitHub hosts a copy of your repository, the remote from the four-areas map, and wraps it in a website: your files and README rendered, every commit browsable, line-by-line views of who changed what. On top of hosting it adds the collaboration layer this course uses: access control (your repos can be private, with your team and the teacher invited), issues (a to-do list attached to the project) and pull requests (reviewed merges, introduced below). For the course, GitHub is where assignments are handed in, where the project is documented, and where "traceable contributions" get read.

Create the repository on GitHub

1. New repository

   On github.com: the + menu (top right) → New repository. Name it my-first-repo, matching the local folder for sanity. Choose Private; course work stays private unless told otherwise, and collaborators see it anyway.

2. Leave it empty

   Do not tick "Add a README", and skip the .gitignore and licence pickers. Your repository already has content and history; a README created on the website would be a commit your local history does not have, and your first push would be rejected. Empty remote, local history: clean first push. (Those checkboxes are for the clone-first way of starting.)

3. Copy the URL

   GitHub then shows the repository's address: https://github.com/username/my-first-repo.git, with your username. The next block uses it. (In Week 3 you will switch to the git@github.com: form, once you have an SSH key.)

Connect and push

> git remote add origin https://github.com/username/my-first-repo.git
> git remote -v            # verify: origin listed twice, fetch and push
origin  https://github.com/username/my-first-repo.git (fetch)
origin  https://github.com/username/my-first-repo.git (push)
> git push -u origin main
Enumerating objects: 9, done.
Writing objects: 100% (9/9), 1.02 KiB | 1.02 MiB/s, done.
To https://github.com/username/my-first-repo.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

• git remote add origin <url> records the address under the conventional nickname origin. One-time, per repository.
• git push -u origin main uploads the main branch's commits. The -u links your local main to origin/main, so from now on plain git push and git pull know where to go. Also one-time; afterwards it is just git push.
• Refresh the repository page in the browser: your README is rendered, and the commits tab shows the history you built. That page is what "hand in on GitHub" means.

How the sign-in works (and what happens in Week 3)

The first push asks GitHub to check you are you. On the lab PCs (and any modern Git for Windows or macOS install), Git Credential Manager opens a browser window: sign in to GitHub, authorize, done. It then remembers the credential, so pushes stop asking. Two things worth knowing:

• Your GitHub password alone does not work in the terminal. Git over HTTPS uses browser sign-in or a personal access token, never the raw password. If a tutorial tells you to type your password at a Git prompt, it is out of date.
• On a shared lab PC, sign out when you leave. Windows: Credential Manager (search it in the Start menu) → Windows Credentials → remove the git:https://github.com entry. Otherwise the next student pushes as you.

Pull: the other direction

git pull downloads new commits from origin and merges them into your branch. You need it the moment the remote knows something your machine does not: a teammate pushed, or you edited a file directly on the GitHub website, or you worked from another computer. Try the website case now: edit README.md on GitHub (pencil icon), commit the change there, then locally:

> git pull
Updating b92ee54..a1b2c3d
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)

Your local file now has the website edit, and the two histories agree again. The habit that prevents most week-one trouble: pull before you start working, push when you stop. The team page turns that habit into a workflow.

The other way to start: clone

> git clone https://github.com/username/my-first-repo.git
> cd my-first-repo

git clone downloads the repository, complete history included, and configures origin automatically, no remote add, no -u. It is the normal first command on a new machine: the lab PC next week, your laptop at home, the Raspberry Pi once it exists. One project, many clones, one shared remote.

Invite your collaborators

A private repository is invisible until you invite people. On the repository page: Settings → Collaborators → Add people, then their GitHub username. For Assignment 1 (next week) you will invite your teammates and the teacher; the exact username to invite is in the assignment instructions on Omnivox. Invitees get an email and must accept. Practise now by inviting your lab partner to today's repository; the next stage needs it.

Pull requests, in one paragraph

On real teams, changes usually reach main through a pull request: you push a branch, open a PR on GitHub, teammates read the diff, comment, and approve before it merges. It is code review built into the hosting, and it is why GitHub is more than a backup service. This course keeps week one simple, your team pushes directly to main, and introduces branches next stage; when the term project grows real features, PRs are the natural upgrade, and GitHub Skills has a free interactive course on them.

Checklist for this stage

• Private repository my-first-repo exists on GitHub, created empty
• git remote -v shows origin with my repository's URL
• git push -u origin main succeeded; the README renders on the repository page
• I edited the README on the website and git pull brought the change down
• My lab partner is invited as a collaborator and has accepted
• I know how to remove the saved GitHub credential from a lab PC

Check yourself