Git & GitHub
Contributor's
Playbook

Run this once per machine before your first commit anywhere, so every commit is correctly attributed to you. Use --global to set it for every repo on your machine, or drop the flag inside a specific repo to override it for that project only (useful for keeping work and personal commits separate).

git init turns any folder into a Git repository, tracked from that point forward. git clone copies a full remote repository — history, branches, and all — onto your machine, and automatically wires it up as the origin remote so you can push and pull immediately.

git status shows what's changed, staged, or untracked — run it constantly, it's free and it prevents mistakes. git add stages files for the next commit; use git add . to stage everything in the current directory, or add files individually when you want a cleaner, more intentional commit. git commit saves the staged snapshot with a message describing what changed and why.

git diff shows exact line-by-line changes before you stage them — always read this before committing, it catches accidental debug code and leftover console logs. git log shows commit history; add --oneline --graph for a compact, visual view of branches and merges that's far easier to scan than the default verbose output.

Every change — a feature, a fix, an experiment — gets its own branch, keeping main always deployable and clean. git switch -c (or the older git checkout -b) creates and switches to a new branch in one step. Name branches descriptively: fix/login-redirect or feat/dark-mode, not branch1.

git merge combines the history of another branch into your current one — usually run on main to bring in a finished feature branch. Merge conflicts happen when the same lines were changed on both sides; Git marks the conflicting sections directly in the file for you to resolve manually, then you stage and commit the resolution.

git push uploads your committed local changes to the remote repository; git pull downloads and merges the latest remote changes into your current branch (it's actually fetch + merge combined). git fetch alone downloads changes without merging — safer when you want to review what changed before integrating it.

git stash temporarily shelves uncommitted changes so you can switch branches cleanly, then git stash pop brings them back. git reset moves your branch pointer backward (use --soft to keep changes staged, --hard to discard them entirely — be careful). git revert is the safe option for shared branches: it creates a new commit that undoes a previous one, without rewriting history.

git rebase replays your branch's commits on top of another branch's latest history, producing a clean, linear timeline instead of a merge-commit web. git rebase -i (interactive) lets you reorder, edit, squash, or drop commits before opening a pull request — most maintainers prefer a tidy, squashed commit history over a dozen "wip" commits.

git cherry-pick applies a single specific commit from another branch onto your current one — useful for backporting a fix without merging an entire branch. git tag marks a specific commit as a named release point (e.g. v1.2.0), which most projects use to track version history and generate changelogs.

Accidentally deleted a branch or reset too far back? git reflog logs every place HEAD has pointed to, even commits that look "lost" after a hard reset. Find the commit hash you need in the reflog, then git reset --hard <hash> or git checkout <hash> to recover it. Almost nothing in Git is truly gone until garbage collection runs.

Tutorials teach syntax; open source teaches you how real production codebases are structured, reviewed, and maintained by teams you've never met. It builds a public portfolio that outlasts any single job, gives you direct exposure to senior engineers' code review feedback for free, and is one of the strongest signals recruiters look for on a resume with limited work experience.

Search GitHub for issues labeled good first issue, help wanted, or beginner-friendly — maintainers tag these specifically for newcomers, and they're usually scoped small enough to finish in a few hours. Use GitHub's own search filters (is:issue is:open label:"good first issue") combined with a language filter to match your skill set.

Prioritize projects you already use or genuinely find interesting — motivation matters more than star count. Check the project's activity: recent commits, responsive maintainers on issues, and an active PR review cadence are better signals than raw popularity. A huge, slow-moving repo with maintainers who haven't replied to an issue in months is a frustrating first experience.

Almost every serious open source project has a CONTRIBUTING.md file outlining exact expectations: coding style, branch naming, commit conventions, how to run tests locally, and the PR review process. Skipping this is the single most common reason first-time PRs get rejected or sent back with change requests — read it fully before opening your editor.

Since you don't have direct write access to most projects, click "Fork" on GitHub to create your own copy under your account, then clone your fork locally — not the original repo. Add the original as an upstream remote so you can pull in the latest changes from the real project as it evolves while you work.

Create a clearly named branch off the latest main, and run the project's existing test suite before you touch anything, to confirm you're starting from a working baseline. Make focused, minimal changes — a PR that fixes one issue is far easier to review and merge than one that also refactors unrelated code "while you're in there."

Follow the project's commit message convention if one exists (many use Conventional Commits: fix:, feat:, docs:). Squash noisy work-in-progress commits into one clean commit with git rebase -i before pushing, then push the branch to your fork, not the original repository.

Reference the issue number (e.g. Closes #123) so GitHub links and auto-closes it on merge. Explain what changed, why, and how you tested it — screenshots or short clips for UI changes are especially appreciated. Expect review comments; treat them as collaboration, not rejection, and respond to every comment even if just to confirm a change was made.