Tutorials · Chapter D (4/4) · ~10 min

GitHub basics

Try it → see it → read → next

Publish Git history to a shared remote and collaborate through branches and pull requests.

Try yourself

Playground

GitHub time machine

Walk commit → branch → recover → PR, with remotes in mind.

1 / 5

→ 1. Make a commit
○ 2. Create a branch
○ 3. Break a file (oops)
○ 4. Recover with checkout / reset
○ 5. Open a PR

Commit locally first — remotes come after a clean history.

Recap

What you just did

GitTimeMachine emphasized remotes and the pull request as a reviewable package of change after you recover locally.

Teach

How it works

A typical feature flow:

git switch -c improve-evaluation
# edit, test, add, and commit
git push -u origin improve-evaluation

Then open a pull request from improve-evaluation into the project’s base branch.

Remote is a hosted copy with a name such as origin
Push sends local commits to a remote branch
Pull request proposes and explains a merge
Review and checks provide evidence before merging

Mental model: Git is the shared language; GitHub is a workshop where people exchange and review that history.

Use it

When you'd use this

Backing up and sharing a code project
Reviewing changes before they reach the main branch
Running tests or deployment checks on each proposal

Watch out

Public repositories are visible to everyone. Remove secrets before the first push—deleting them in a later commit may not erase history. Do not merge failing checks or unclear changes merely because the branch pushes successfully.

Try next

Try this next

Write a pull-request summary with one sentence for the change and two concrete test steps.