GitHub Tutorial for Beginners (2025): From Zero to First Pull Request

GitHub is where over 100 million developers store, share, and collaborate on code. Whether you're building your first project or joining an open-source team, this guide walks you through every step — no prior experience required.

What you'll learn

Part 1 — Git vs GitHub

Before touching GitHub, understand what each tool does.

Git is version control software that runs on your computer. It tracks every change to your files.

GitHub is a cloud platform built on top of Git. It hosts your Git repositories online and adds collaboration features: pull requests, code review, CI/CD, issue tracking, and more.

Your laptop                   GitHub (cloud)
-----------                   --------------
Git (local)  ──── push ────▶  Remote repo
             ◀─── pull ────   (github.com/you/project)

You can use Git without GitHub, but GitHub without Git makes no sense. Learn them together.

Part 2 — Account setup

2.1 Create a GitHub account

Go to github.com and sign up. Choose a username that's professional — it shows up on your profile, commit history, and public contributions.

2.2 Install Git

Check if Git is already installed:

git --version
# git version 2.45.0

If not, install it:

2.3 Configure Git

Tell Git who you are. Use the same email as your GitHub account:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global core.editor "code --wait"   # use VS Code as editor

Verify:

git config --list

2.4 Set up SSH (recommended)

SSH lets you push/pull without entering your password every time.

Generate an SSH key:

ssh-keygen -t ed25519 -C "you@example.com"
# Press Enter to accept default location (~/.ssh/id_ed25519)
# Optionally set a passphrase

Add the public key to GitHub:

cat ~/.ssh/id_ed25519.pub
# Copy the output

Go to GitHub → Settings → SSH and GPG keys → New SSH key, paste it, and save.

Test the connection:

ssh -T git@github.com
# Hi yourusername! You've successfully authenticated.

Part 3 — Your first repository

3.1 Create a repo on GitHub

1. Click the + button → New repository
2. Fill in:
   • Repository name: my-first-project
   • Description: optional but helpful
   • Visibility: Public (visible to everyone) or Private
   • Initialize with README: check this for new projects
3. Click Create repository

You now have a remote repository at github.com/yourusername/my-first-project.

3.2 Clone the repo to your computer

Cloning downloads the repo and sets up the remote connection:

git clone git@github.com:yourusername/my-first-project.git
cd my-first-project
ls
# README.md

3.3 Understand the folder structure

my-first-project/
├── .git/          ← hidden folder, Git's brain (don't touch)
└── README.md      ← your project description

The .git/ folder is where Git stores all history, branches, and configuration. Never delete or manually edit it.

Part 4 — The core Git workflow

Every day of coding follows the same loop: edit files → stage changes → commit → push.

Edit files   →   git add   →   git commit   →   git push
(working dir)   (staging)    (local history)   (GitHub)

4.1 Make your first change

Edit README.md:

# My First Project

A project I built while learning GitHub.

## Features
- Feature 1
- Feature 2

4.2 Check what changed

git status
# On branch main
# Changes not staged for commit:
#   modified:   README.md

git diff README.md
# Lines starting with + are added
# Lines starting with - are removed

4.3 Stage changes

git add README.md         # stage one file
git add .                 # stage all changed files

Staging lets you choose exactly what goes into each commit. A commit should be one logical change.

4.4 Commit

git commit -m "Add project description to README"

A good commit message:

• Uses imperative mood: "Add", "Fix", "Update" (not "Added" or "Adding")
• Explains what changed and optionally why
• Is under 72 characters for the first line

# Good
git commit -m "Fix null pointer error in user login"

# Bad
git commit -m "stuff" 
git commit -m "fixed things and also updated some files"

4.5 Push to GitHub

git push origin main

Now open GitHub in your browser — your changes are live.

Summary: daily workflow

# Start of day: get latest changes
git pull origin main

# Work on code, then:
git status              # see what changed
git add .               # stage everything (or specific files)
git commit -m "message" # save the snapshot
git push origin main    # send to GitHub

Part 5 — Branches

Branches let you work on features without touching the main branch. Think of them as parallel universes of your code.

main:    A ── B ── C ──────────── F  (merge)
                    \            /
feature:             D ── E ────

5.1 Create and switch to a branch

git checkout -b feature/add-login
# or with modern Git (2.23+)
git switch -c feature/add-login

5.2 Work on the branch

Make changes, stage, commit as usual:

# Edit files...
git add .
git commit -m "Add login form component"
git push origin feature/add-login

5.3 List branches

git branch          # local branches
git branch -a       # local + remote branches

5.4 Switch between branches

git checkout main
git switch main   # modern syntax

5.5 Merge a branch (locally)

git checkout main
git merge feature/add-login
git push origin main

In practice, you'll merge through pull requests on GitHub instead (see Part 6).

5.6 Delete a branch after merging

git branch -d feature/add-login        # delete local
git push origin --delete feature/add-login  # delete remote

Branch naming conventions

Part 6 — Pull requests

A pull request (PR) is how you propose changes to a codebase. It's the core collaboration tool on GitHub.

6.1 Open a pull request

1. Push your branch to GitHub (git push origin feature/add-login)
2. GitHub shows a banner: "Compare & pull request" — click it
3. Fill in:
   • Title: clear and concise ("Add login form with validation")
   • Description: what you changed, why, how to test it
   • Reviewers: tag teammates to review your code
4. Click Create pull request

6.2 PR description template

## What changed
- Added login form with email/password fields
- Added form validation (empty fields, email format)
- Wired up POST /api/auth/login endpoint

## Why
Users need to log in to access their dashboard (#123)

## How to test
1. Go to /login
2. Try submitting empty form — should show errors
3. Submit valid credentials — should redirect to /dashboard

## Screenshots
[paste screenshot here]

6.3 Code review

Reviewers can:

• Leave line comments on specific code
• Approve the PR (✅ ready to merge)
• Request changes (🔄 needs updates before merging)

As the author, respond to every comment — either fix the code and reply "Done ✅" or explain why you disagree.

6.4 Merge the PR

Once approved, click Merge pull request. Choose:

After merging, delete the branch (GitHub prompts you).

6.5 Update your local main

git checkout main
git pull origin main
git branch -d feature/add-login  # clean up local branch

Part 7 — Forking and contributing to open source

Forking creates a copy of someone else's repo under your account. You can then contribute back via pull request.

7.1 Fork a repo

Click Fork on any public repo. You now have github.com/yourusername/original-project.

7.2 Clone your fork

git clone git@github.com:yourusername/original-project.git
cd original-project

7.3 Add the upstream remote

Keep a reference to the original repo:

git remote add upstream git@github.com:originalowner/original-project.git
git remote -v
# origin    git@github.com:yourusername/original-project.git (fetch)
# origin    git@github.com:yourusername/original-project.git (push)
# upstream  git@github.com:originalowner/original-project.git (fetch)
# upstream  git@github.com:originalowner/original-project.git (push)

7.4 Stay in sync with upstream

git fetch upstream
git checkout main
git merge upstream/main
git push origin main

7.5 Make changes and open a PR

1. Create a branch: git checkout -b fix/typo-in-docs
2. Make changes, commit, push to your fork
3. Open a PR from yourusername:fix/typo-in-docs → originalowner:main

Part 8 — GitHub essentials

8.1 Issues

Issues track bugs, feature requests, and tasks. Use labels (bug, enhancement, good first issue) to organise them.

**Bug report example:**

**What happened:**
Login button does nothing when clicked on Safari 17

**Steps to reproduce:**
1. Go to /login
2. Enter valid credentials
3. Click "Sign in"

**Expected:** Redirect to dashboard
**Actual:** Nothing happens, no error in console

**Environment:** Safari 17 / macOS Sonoma

Link a PR to an issue: include Closes #42 in the PR description — it auto-closes the issue when merged.

8.2 README.md

Your README is the front page of your project. Include:

# Project Name

One sentence description.

## Quick start

\`\`\`bash
git clone ...
npm install
npm run dev
\`\`\`

## Features
- Feature 1
- Feature 2

## Tech stack
- Next.js / React
- PostgreSQL
- Tailwind CSS

## Contributing
See [CONTRIBUTING.md](./CONTRIBUTING.md)

## License
MIT

8.3 .gitignore

The .gitignore file tells Git which files to never track:

# Node
node_modules/
.env
.env.local

# Build output
dist/
build/
.next/

# OS files
.DS_Store
Thumbs.db

# Editor
.vscode/
*.swp

GitHub provides starter .gitignore templates for every language when you create a repo.

8.4 GitHub Actions (CI/CD)

GitHub Actions runs automated workflows: run tests on every push, deploy on merge to main.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Every PR now shows a ✅ or ❌ status based on whether tests pass.

Part 9 — Common Git commands reference

Part 10 — GitHub workflow for teams

10.1 GitHub Flow (simple, recommended for most teams)

main always deployable
│
├── feature/user-auth    ← branch
├── fix/navbar-bug       ← branch
└── docs/api-reference   ← branch

Each branch → Pull Request → Review → Merge → Delete branch

Rules:

1. main is always deployable
2. Create a branch for every change
3. Open a PR early (use Draft PRs for work in progress)
4. Merge only after review + CI passes

10.2 Commit message conventions

Many teams use Conventional Commits:

<type>(<scope>): <description>

feat(auth): add Google OAuth login
fix(api): handle null user ID in profile endpoint
docs(readme): add deployment section
test(cart): add integration tests for checkout
chore(deps): upgrade React to 19.1.0

Types: feat, fix, docs, test, chore, refactor, perf, ci

10.3 Protected branches

On GitHub, go to Settings → Branches → Add rule to protect main:

• Require pull requests before merging
• Require status checks to pass (CI)
• Require at least 1 approval
• Prevent force pushes

Common mistakes

GitHub vs. alternatives

FAQ

Do I need to pay for GitHub?
No. The free plan includes unlimited public and private repos, GitHub Actions minutes (2,000/month), and collaboration for up to 3 people on private repos. GitHub Pro adds more minutes and features for $4/month.

What's the difference between git pull and git fetch?
git fetch downloads remote changes but doesn't apply them. git pull does fetch + merge in one step. Use git fetch when you want to review changes before merging.

Can I undo a commit I already pushed?
Yes, but carefully. git revert <hash> creates a new commit that undoes the change — safe for shared branches. git reset --hard HEAD~1 + git push --force rewrites history — only safe on your own branches, never on shared ones.

What's a fork vs a branch?
A branch is inside the same repository. A fork is a copy of a repo under your own GitHub account. You fork when you want to contribute to a repo you don't have write access to.

How do I fix a merge conflict?
Git marks conflicting sections like this:

<<<<<<< HEAD
your version of the code
=======
their version of the code
>>>>>>> feature/other-branch

Edit the file to keep what you want, remove the markers, then git add and git commit.

Should I use HTTPS or SSH?
SSH is recommended — you set it up once and never type passwords. HTTPS requires typing your credentials (or using a credential manager) on each push. If you're on a shared machine, HTTPS might be safer since SSH keys stay on the device.

Next steps

Now that you know the basics:

1. Practice — Create a repo for a personal project and commit daily
2. Explore — Browse open-source repos on GitHub, read their code
3. Contribute — Find a "good first issue" on any popular project and open a PR
4. Go deeper — Learn git rebase, git stash workflows, and GitHub Actions
5. Build your profile — Public contributions show up on your profile's activity graph — employers look at it

The best way to learn GitHub is to use it every day. Start with your own projects, then collaborate with others.