DaleSchool

Getting Started with GitHub

Beginner25min

Learning Objectives

  • Create and manage GitHub repositories
  • Explain the roles of Issues and Pull Requests
  • Understand the Pull Request code review cycle
  • Explain the purpose of Draft PRs

Working Code

Example 1: Creating a repository with GitHub CLI

Install GitHub CLI (gh) to manage GitHub from the terminal:

brew install gh
gh auth login

Create a repository:

cd ~/my-project
gh repo create my-project --public --push --source=.

This single command:

  1. Creates a repository on GitHub
  2. Sets up the origin remote
  3. Pushes the current code

Verify:

gh repo view --web   # Open in browser

Example 2: Creating an issue

gh issue create \
  --title "Login page bug" \
  --body "Auto-login doesn't work after password reset."

Output:

https://github.com/username/my-project/issues/1

List issues:

gh issue list

Output:

ID  TITLE                   LABELS  UPDATED
1   Login page bug                  2 minutes ago

Example 3: Creating a Pull Request

# Work on a feature branch
git checkout -b fix/login-bug
echo "// Bug fix code" > login-fix.js
git add login-fix.js
git commit -m "fix: fix auto-login bug after password reset"
git push origin fix/login-bug

gh pr create \
  --title "fix: fix login bug" \
  --body "Resolves #1

  ## Changes
  - Fixed session refresh logic after password reset"

Try It Yourself

Pull Request code review cycle

After creating a PR, teammates review the code:

Developer                         Reviewer
   |                                 |
   |-- Create PR -----------------> |
   |                                 |-- Review code
   |                                 |-- Leave comments
   | <-- Review feedback ---------- |
   |
   |-- Commit fixes
   |-- git push (PR auto-updates)
   |
   |-- Request re-review ----------> |
   |                                 |-- Re-review
   |                                 |-- Approve
   | <-- Approval ----------------- |
   |
   |-- Merge PR
   |-- Delete branch

Responding to review feedback:

# Reviewer commented: "Make the variable names clearer"
vim login-fix.js   # Make changes
git add login-fix.js
git commit -m "refactor: clarify variable names"
git push   # Automatically reflected in the PR

Since the PR tracks the branch, pushing updates it automatically.

PR list and details:

gh pr list

gh pr view 1   # View PR #1 details

gh pr view 1 --web   # Open in browser

Merging a PR:

gh pr merge 1 --squash   # Squash merge (combine feature commits into one)
gh pr merge 1 --merge    # Merge commit
gh pr merge 1 --rebase   # Rebase merge

Draft PR: Signal work in progress

# Draft PR: when it's not ready for review yet
gh pr create \
  --title "feat: implement payment system" \
  --body "Work in progress..." \
  --draft

Draft PR use cases:

  • Signal "still working on this, don't review yet"
  • Share progress with the team
  • Check CI test results
  • Request early feedback

Convert to ready for review:

gh pr ready 1

"Why?" -- GitHub is more than a code host

GitHub is Git repository hosting + a collaboration platform.

| Feature | Purpose | | ---------------- | -------------------------------------------- | | Issues | Bug reports, feature requests, task tracking | | Pull Request | Code review + merge request | | Actions | CI/CD automation | | Projects | Kanban board for task management | | Discussions | Team discussions |

Pull Request workflow

Create issue (#1 "Login bug")
    |
Create branch (fix/login-bug)
    |
Fix code + commit (closes #1)
    |
Create PR (request code review)
    |
Code review + feedback
    |
Apply fixes + re-review
    |
Approve -> Merge
    |
Delete branch + issue auto-closes

Including closes #1 or fixes #1 in the commit message or PR body auto-closes the issue when the PR is merged.

Checking CI status

Check GitHub Actions results on a PR:

gh pr checks 1

Output:

All checks were successful
✓ CI / test (2m 15s)
✓ CI / lint (45s)

You can block merging when CI fails.

Common Mistakes

Mistake 1: Vague PR titles

# Bad
update
fix
changes

# Good
fix: fix auto-login bug after password reset
feat: add Google social login
docs: add authentication section to API docs

Mistake 2: Too many changes in one PR

# Avoid: dozens of file changes in one PR
# Hard to review and increases merge conflict risk

# Recommended: one purpose per PR
# "Login feature" PR -> only login.js, auth.js, and related tests

Mistake 3: Pushing directly to main without review

# Bad habit
git push origin main   # Direct push

# Good habit
# 1. Create a feature branch
# 2. Work + commit
# 3. Create a PR
# 4. Get reviewed
# 5. Merge the PR

Branch protection rules can block direct pushes.

Deep Dive

Forks and open-source contributions

When you don't have push access to a repository:

  1. Fork: Copy the repository to your account
  2. Clone: Clone your fork locally
  3. Branch + edit + push (to your fork)
  4. PR: Submit a contribution request to the original repository
# Sync with original (set up upstream)
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git merge upstream/main
Setting up a PR template

Create a .github/PULL_REQUEST_TEMPLATE.md file to auto-fill PR descriptions:

## Changes

-

## Related Issue

closes #

## Checklist

- [ ] Feature implemented
- [ ] Tests added
- [ ] Documentation updated
- [ ] Browser tested

## Screenshots (for UI changes)
Useful GitHub keyboard shortcuts

On the GitHub website:

  • t -- File search
  • b -- Switch branches
  • . -- Open web editor (vscode.dev)
  • Ctrl+K -- Command palette
  • gc -- Go to commit list
  1. Create a new GitHub repository and connect it locally.
  2. Create an issue with gh issue create.
  3. Work on a new branch, then create a PR with gh pr create. Include the issue number in the body.
  4. Create a Draft PR and convert it to ready with gh pr ready.
  5. Merge with gh pr merge --squash and check if the issue auto-closes.

Q1. What is the primary purpose of a Pull Request?

  • A) Uploading code to a remote repository
  • B) Automatically deleting branches
  • C) Requesting a branch merge through code review
  • D) Automatically resolving conflicts