🐙 GitHub Platform Introduction

You already know Git — the engine that tracks your changes. GitHub is the whole vehicle built around that engine: a cloud home for your repositories plus the collaboration, automation, and security tools that make team development possible. This lesson maps out what GitHub adds and how to start using it well.

🎯 Learning Objectives

By the end of this lesson, you will be able to:

Explain the difference between Git and GitHub and where each fits in your workflow
Create a repository, connect a local project, and authenticate securely with SSH keys
Navigate the key repository tabs — Code, Issues, Pull Requests, Actions, Insights, Settings
Use issues, labels, and branch protection to organize collaborative work
Describe the fork-and-pull-request model used for open-source contribution

Estimated Time: 35–45 minutes • Difficulty: Beginner

Hands-on: Create a repository, add SSH authentication, and push your first commit to GitHub.

In This Lesson

Git vs. GitHub

These two names get used interchangeably, but they are not the same thing — and understanding the split makes everything else click.

💡 A useful analogy: Git is the engine — the version-control software that runs on your own computer and tracks changes to files. GitHub is the whole car built around that engine: a place to park your repositories in the cloud, plus navigation (issues), safety features (code review, branch protection), and passenger seats (collaborators).

	Git	GitHub
What it is	Distributed version-control software	A cloud hosting & collaboration platform
Where it runs	Locally, on your machine	In the browser (and via APIs/CLI)
Who makes it	Open-source community	A product owned by Microsoft (since 2018)
Main job	Track changes over time	Enhance collaboration around those changes

GitHub is not the only Git host — GitLab, Bitbucket, Gitea, and Azure DevOps all offer similar features, and most of the concepts in this lesson transfer to them. But GitHub's network effect — hundreds of millions of repositories and the home of most major open-source projects — has made it the industry default. Learn it here and the others feel familiar.

The GitHub Ecosystem

GitHub bundles five broad families of features on top of plain Git. You will not touch every one on day one, but it helps to know the map:

flowchart TD A[GitHub Platform] --> B[Code Hosting] A --> C[Collaboration] A --> D[Project Management] A --> E[CI/CD Automation] A --> F[Community] B --> B1[Repositories & branches] B --> B2[Browse, search, blame] C --> C1[Pull requests] C --> C2[Code reviews] C --> C3[Issues & discussions] D --> D1[Projects & boards] D --> D2[Milestones] E --> E1[GitHub Actions] E --> E2[Packages & Pages] F --> F1[Open-source discovery] F --> F2[Profiles & Sponsors]

📖 Key Terms

Repository (repo): the central unit of organization on GitHub — one project's files, history, issues, and settings.

Remote: a named reference to a hosted copy of a repository. origin is the conventional name for your GitHub copy.

Fork: your own server-side copy of someone else's repository, which you can change freely and later propose merging back.

Getting Started & SSH

After you sign up and pick a professional username (it becomes your identity: github.com/username), the most important setup step is authentication. GitHub no longer accepts account passwords over the command line, so you will authenticate with an SSH key — a cryptographic key pair that proves who you are without typing a password each time.

Generate and register an SSH key

# 1. Check for existing keys
ls -la ~/.ssh

# 2. Generate a modern Ed25519 key (press Enter to accept the default path)
ssh-keygen -t ed25519 -C "your_email@example.com"

# 3. Start the SSH agent and add the private key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 4. Copy the PUBLIC key to your clipboard
#    macOS:
pbcopy < ~/.ssh/id_ed25519.pub
#    Windows (Git Bash):
clip < ~/.ssh/id_ed25519.pub
#    Linux (then copy the printed text):
cat ~/.ssh/id_ed25519.pub

Then in GitHub go to Settings → SSH and GPG keys → New SSH key, paste the public key, give it a descriptive title, and save. Verify the connection:

ssh -T git@github.com
# Expected: "Hi username! You've successfully authenticated..."

⚠️ Public vs. private key

Only ever upload the .pub (public) file. The matching private key — the file without the extension — never leaves your machine. Treat it like a house key: if it leaks, anyone can act as you.

Create a repository and connect it

Click New repository, name it in kebab-case, choose public or private, and optionally add a README, a .gitignore, and a license. Then wire up a local project:

# Inside your existing local project
git remote add origin git@github.com:username/repository-name.git
git remote -v                    # confirm the remote is set
git push -u origin main          # push and set the upstream branch

Or start from GitHub's copy by cloning:

git clone git@github.com:username/repository-name.git
cd repository-name

Anatomy of a Repository

Every repository presents the same set of tabs across the top. Knowing what lives where turns GitHub from a wall of buttons into a familiar workspace:

Figure 1 — The core repository tabs. Code holds your files and history; Issues and Pull Requests are where collaboration happens; Actions automates work; Insights and Settings manage the project.

Two features deserve special attention early on:

Blame view — on any file, shows who last changed each line and in which commit. Invaluable when you need to ask "why is this here?"
Branch protection — rules on the main branch that block direct pushes and require a reviewed pull request (and passing checks) before merging. This is how teams keep the main line stable.

💡 The default branch

New GitHub repositories name their primary branch main. Older projects and tutorials may use master; the two are functionally identical — just a name.

Collaboration: Issues & Permissions

GitHub's collaborative features are what set it apart from plain Git. The two you will use most are issues and access control.

Issues: tracking work and bugs

An issue is a lightweight record for a bug, feature request, or task. It has a title, a description, labels for categorization, assignees, and an optional milestone. Standardize them with a template stored in .github/ISSUE_TEMPLATE/:

---
name: Bug report
about: Create a report to help us improve
title: '[BUG] '
labels: bug
---

**Describe the bug**
A clear and concise description of what the bug is.

**To reproduce**
1. Go to '...'
2. Click on '...'
3. See error

**Expected behavior**
What you expected to happen.

**Environment**
- OS:
- Browser:
- Version:

You can close issues automatically from a pull request by writing a linking keyword in the PR description — GitHub understands fixes #123, closes #123, and resolves #123. When the PR merges, the referenced issue closes on its own.

Permission levels

GitHub grants access in graduated levels — a practical application of the principle of least privilege: give each person only the access they actually need.

Level	Can do
Read	View and clone the repository
Triage	Manage issues and PRs without write access
Write	Push branches and manage issues/PRs
Maintain	Manage the repo, minus destructive/sensitive actions
Admin	Full control, including deletion and settings

For larger groups, Organizations let you assign permissions to entire teams at once and @mention a team to notify everyone in it.

Contributing to Open Source

GitHub is the world's largest host of open-source software, and contributing to it follows one dominant pattern: fork and pull request. You can't push directly to a project you don't own, so you copy it, change your copy, and propose your changes back.

flowchart LR A[Fork the repo] --> B[Clone your fork] B --> C[Create a branch] C --> D[Make & commit changes] D --> E[Push to your fork] E --> F[Open a pull request] F --> G[Address feedback] G --> H[Maintainer merges]

The one extra step beyond a normal branch workflow is keeping your fork in sync with the original, which is conventionally named upstream:

# Point at the original project (once)
git remote add upstream https://github.com/original-owner/project.git

# Later, pull in the latest changes before you start work
git checkout main
git fetch upstream
git merge upstream/main
git push origin main

✅ Starting your own open-source project?

A welcoming project ships more than code. Include a clear README.md, a LICENSE, a CONTRIBUTING.md with contribution guidelines, a CODE_OF_CONDUCT.md, and a SECURITY.md explaining how to report vulnerabilities. These set expectations and make it far easier for others to help.

Hands-on Exercise

🏋️ Publish your first repository

Objective: Take a small local project all the way onto GitHub using SSH authentication.

Instructions:

If you have not already, generate an SSH key and add it to your GitHub account (see the SSH section above). Confirm with ssh -T git@github.com.

Create a new folder, initialize Git, and make a first commit:

mkdir hello-github && cd hello-github
echo "# Hello GitHub" > README.md
git init
git add README.md
git commit -m "Initial commit"

On GitHub, create a new empty repository named hello-github (do not initialize it with a README — you already have one).

Connect and push:

git remote add origin git@github.com:YOUR_USERNAME/hello-github.git
git branch -M main
git push -u origin main

Refresh the repository page and confirm your README appears. Then open an issue titled "Add a project description" to practice the collaboration tools.

💡 Hint

If git push reports "Permission denied (publickey)", your SSH key isn't loaded. Run ssh-add ~/.ssh/id_ed25519 and try again. If it says the remote already has commits, you likely initialized the GitHub repo with a README — run git pull origin main --rebase first, then push.

✅ What success looks like

Your terminal reports the branch was pushed and set to track origin/main. The GitHub page shows one commit ("Initial commit") and renders your README. Your new issue appears under the Issues tab with the number #1.

🎯 Quick Quiz

Question 1: Which statement best describes the relationship between Git and GitHub?

Question 2: When setting up SSH authentication, which file do you upload to GitHub?

Question 3: To contribute to a project you do not have write access to, what is the standard workflow?

Best Practices

✅ Do

Enable two-factor authentication on your account — GitHub now requires it for many contributors anyway.
Protect main with branch-protection rules so nothing merges without review and passing checks.
Write a real README: what the project does, how to install it, how to run it.
Use issues and labels to make work visible and traceable back to code.

⚠️ Don't

Never commit secrets — API keys, tokens, passwords. Use a .gitignore and GitHub Secrets instead, and enable secret scanning.
Don't hand out Admin access by default; grant the least privilege each role needs.
Don't push your private SSH key or paste it anywhere — only the .pub file is ever shared.

Summary & Quiz

🎉 Key Takeaways

Git tracks changes locally; GitHub hosts those repositories and layers on collaboration, automation, and security.
Authenticate with an SSH key — upload only the public .pub file, keep the private key on your machine.
A repository is organized into tabs: Code, Issues, Pull Requests, Actions, Insights, Settings.
Issues, labels, and branch protection keep collaborative work organized and the main branch stable.
Open-source contribution follows the fork-and-pull-request model, keeping your fork synced with upstream.

📚 Further Reading

🚀 What's Next?

Next we'll zoom in on the single most important collaboration feature on GitHub — the pull request — and learn how to write, review, and merge one professionally.

🎉 Well done!

You've gone from Git on your laptop to a project living in the cloud. Now let's make it a team sport.