Git & GitHub Without Fear

Git remembers; GitHub helps people collaborate.

What if your best code disappeared—or yesterday's version was actually better? Git gives your project a memory, so experimenting stops feeling like gambling.

Git and GitHub are related, but they are not the same tool. Git is a distributed version-control system: it records intentional snapshots of files in a repository. It works on your computer and most everyday commands work offline. GitHub is an online service that can host Git repositories and add issues, pull requests, reviews and automated Actions.

Developers use them to understand what changed, return to known work, try ideas on branches, review changes before merging and share projects. Git is useful for HTML, CSS, JavaScript, Python, notes and almost any text-based project.

Repository: A project folder plus its Git history.
Commit: An intentional snapshot with a message explaining why it exists.
Branch: A movable name for a line of work.
Remote: A named connection to another repository, often one hosted on GitHub.
Pull request: A GitHub conversation for reviewing proposed changes before merging them.
Star: An optional bookmark and signal of appreciation. It does not copy a project or affect your grade.
Template: An independent starter copy. Use this for KODE Ń VIBE graded projects.
Fork: A copy connected to an upstream repository, used when proposing contributions back.

Plain-English modelYour files are the current draft. Git is the project history you decide to record. GitHub is a shared workspace where that history can be backed by discussion, review and checks.

Did you know?Git was created in 2005 for Linux kernel development. A commit is not an automatic backup: it records only what you deliberately stage and commit, and a local commit is not on GitHub until you push it.

Two-minute check

I can explain Git without mentioning GitHub. I know a commit is an intentional snapshot, not autosave. I can name one reason to use a branch.

Install Git first; create GitHub only when sharing begins.

Use the free installation guide for current Windows, macOS and Ubuntu steps. Verify the result with git --version. Git does not require an account. GitHub does: create one at the official site, verify the email, choose a unique password, enable two-factor authentication and store the recovery codes somewhere safe.

git --version
git config --global user.name "Your public name"
git config --global user.email "your-verified-email@example.com"
git config --global init.defaultBranch main
git config --global --list

Your Git name and email label commits; they do not sign you in. For HTTPS authentication, use GitHub CLI or a supported credential manager. Do not paste passwords, one-time codes or access tokens into a repository, screenshot or tutorial.

Account safetyUse a public email or GitHub-provided no-reply address if you do not want a private address in commit history. Never use plaintext credential storage. GitHub no longer accepts account passwords for Git command-line HTTPS authentication.

Setup proof

git --version prints a version. My default branch is main. GitHub 2FA is enabled and recovery codes are stored safely. I understand that identity configuration and authentication are separate.

Inspect, select, record.

A useful beginner model has three states: the working tree contains current files, the staging area selects the exact next snapshot, and HEAD identifies the currently checked-out commit. Use git status between steps so Git explains the state.

mkdir learning-log
cd learning-log
git init
printf "# Learning log
" > README.md

git status
git diff
git add README.md
git diff --cached
git commit -m "docs: start learning log"
git log --oneline --decorate

Stage specific files or even selected lines. Avoid reflexively running git add . before inspecting the diff. A good commit contains one coherent change and a message that helps a future reader understand its purpose.

# Ignore generated and private local files.
node_modules/
.env
dist/

# Keep a safe example file.
!.env.example

.gitignore affects untracked files. It does not erase a secret that Git already tracks or remove it from history.

Why have a staging area?

It lets you choose a clean snapshot from a messy working folder. You can commit one finished idea while leaving unrelated work for later.

Branches make change reviewable.

git switch -c feature/clear-empty-state
# edit, inspect, stage and commit
git push -u origin feature/clear-empty-state

Open a pull request with the problem, the chosen change, screenshots or test evidence, and remaining limits. If Git reports a conflict, read both versions, edit the file into the intended result, test it, stage it and complete the merge. Do not delete markers blindly.

Use the least destructive recovery tool

git restore file discards an uncommitted file change—inspect first.
git restore --staged file removes a path from the next snapshot without deleting the working file.
git revert <commit> adds a new commit that reverses published history.
git reflog can help locate recently moved local references.

GitHub Actions can automatically run tests for a pushed revision. A green check proves only the programmed checks passed; it does not prove authorship, usability, accessibility or production safety.

45–60 min