Git and GitHub Basics

Updated 26 September 2026 · 6 min read

Git is a version control system: it records snapshots of your files so you can see what changed, undo a mistake, and work on a feature without destroying the last working copy. GitHub is a popular website that hosts Git repositories remotely so you have an off-machine copy and a place to collaborate. This lesson covers why version control exists, the words repository, commit, and branch, the everyday commands (init, add, commit, log, status), pushing to a remote, and a daily workflow. Command flags and screens change; check official Git and GitHub documentation when something on your machine differs. This is not a hosting or salary guide.

Why version control

Without Git, people duplicate folders: guess-final.py, guess-final2.py, guess-really-final.py. You cannot tell what changed, you cannot go back cleanly, and you cannot merge two honest attempts. Git stores a history of commits inside a hidden .git directory. You still have one working folder. The history is extra.

You want Git as soon as a program works and you are about to “improve” it. That is the moment you will break it. A commit is a bookmark that says “this ran.” Combined with the debugging habits in reading error messages, you can return to a known good file instead of reconstructing it from memory.

Git runs locally. You do not need an account to init and commit. GitHub (or any other host) is optional until you want a backup or a second computer.

Repository, commit, branch

A repository (repo) is a project folder tracked by Git. A commit is a snapshot with a message, an author, and a pointer to the previous commit. A branch is a movable name pointing at a commit. main (or older repos’ master) is the default branch name you will see a lot.

You work on files, stage the ones you want in the next snapshot, then commit. Staging exists so you can commit related changes together and leave half-finished experiments unstaged. A branch lets you try an idea without moving main until you are ready. Beginners can stay on main for tiny personal projects. Learn branches before you juggle several features at once.

None of this replaces writing a program. It sits beside your first Python program as a way to keep that file’s history.

init, add, commit, status, log

In a project folder (do not init in your entire home directory):

git init
git status
git add guess.py
git commit -m "Add number guessing game"
git log --oneline

git init creates .git. git status tells you which files are untracked, staged, or modified. git add stages. git commit records a snapshot. The -m flag puts the message on the command line; otherwise Git opens an editor. Messages should describe the change, in the imperative mood if you like (“Add guessing game”), not “stuff.”

Configure your name and email once per machine if Git asks (those labels go on commits). Use an email you are willing to have in history. You can set them with git config --global user.name and user.email as the official docs show.

If git is not installed, install it from the official Git project or your operating system’s packages, then retry. Windows users often get Git from the official installer and use Git Bash or a terminal that can find git.

What to commit, what to ignore

Commit source you wrote: .py, .html, .css, a README. Do not commit giant binary junk, secret keys, or files that can be rebuilt. A .gitignore file lists patterns to skip:

__pycache__/
.env
*.pyc

If you accidentally commit a secret, rotating the secret is the real fix; deleting the file in a later commit does not erase it from history. Treat that as a reason to be careful, not as a full security course.

Commit often enough that each commit is one idea. “Add loop” then “Fix TypeError on empty input” is easier to undo than “lots of work Friday.”

Pushing to a remote

A remote is another copy of the repo, usually on a host. GitHub is one host. Create an empty repository on the website (no README if you already committed locally, to avoid a merge puzzle on day one), then GitHub shows commands. The shape is:

git remote add origin https://github.com/EXAMPLE/guessing-game.git
git push -u origin main

Use your real URL, not EXAMPLE. Authentication may be a credential helper, SSH keys, or a token — follow GitHub’s current docs. origin is a conventional remote name. push sends commits you have that the remote does not. pull brings commits the remote has that you do not. On a solo project with one computer, you will push more than you pull until you use a second machine.

Public repos are visible to the world. Do not put private data in them. Private repos exist on GitHub with account limits that change; read the host’s own pages rather than this article for plans.

Official project homes worth bookmarking: Git and GitHub (two homepages, the maximum this site allows). Use them for installers and current CLI syntax.

A daily workflow

1. git status — know whether you have uncommitted work before you start.
2. Write code. Run it. See tests or a manual check pass.
3. git diff — read the change. Catch a debug print or a file you did not mean.
4. git add the files that belong together.
5. git commit -m "…" with a sentence you will understand next month.
6. git push if you use a remote, especially before you close the laptop.

When you try a risky idea, create a branch:

git switch -c try-hints
# edit, commit
git switch main
# merge later with git merge try-hints when you want it

Older Git uses git checkout -b instead of switch. Both exist. If switch is missing, your Git is older; use checkout or upgrade.

If Git refuses a push because the remote has commits you lack, git pull (or pull with rebase, once you know what that means) then push. Do not --force on a shared main branch until you understand you are rewriting published history.

Mistakes you can recover from

Changed a file and want the last commit’s version: git restore guess.py (older: git checkout -- guess.py). Unstage: git restore --staged guess.py. These are everyday tools. Rewriting old public commits is not an everyday tool.

You cannot restore what was never committed. That is why “commit the working game before refactoring” is the whole sermon. A 90-day learning stretch, as in a 90-day learning plan, should include “commit when it runs,” not only “watch another video.”

git log and git show let you read history. You do not need a GUI. GUIs are fine if they show the same status, diff, and commit actions and do not hide errors.

Checklist

• Git tracks snapshots in a repo; GitHub hosts a copy if you push.
• status, add, commit, log are the local core.
• Commit source, ignore secrets and junk, write real messages.
• Push when you have a remote; pull before you fight a divergent history.
• Commit before refactors; restore is for committed work.
• Stay on one branch until a second idea would wreck the first.

Initialize a repo in the folder that holds your guessing game today. Make one commit that only adds the working file. That single snapshot is already more professional than a desktop of final2 copies.

Related lessons

• A 90-Day Plan for Learning to Code
• What Programming Really Is
• Choosing Your First Programming Language

Beginner-level guidance; tools and versions change, so check official documentation for details.