Git is a version control system. It tracks every change you make to your code, lets you undo mistakes, work on features in parallel, and collaborate with other people without overwriting each other's work. Nearly every software project uses Git, and services like GitHub and GitLab provide online hosting for your Git repositories.

Installing Git

• macOS: Install with Homebrew: brew install git. Or it comes with Apple's Command Line Tools (run xcode-select --install)
• Windows: Install with winget: winget install Git.Git. Or download from git-scm.com
• Linux: Use your package manager: sudo apt install git (Debian/Ubuntu), sudo dnf install git (Fedora), or sudo pacman -S git (Arch)

Verify it's installed by running:

git --version

Initial setup

Tell Git your name and email. These are attached to every commit you make:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Set your default branch name to main (the modern convention):

git config --global init.defaultBranch main

Core concepts

A repository (or "repo") is a project folder tracked by Git. Inside it, a hidden .git folder stores the entire history of changes.

The basic flow is:

1. Make changes to files
2. Stage the changes you want to save (git add)
3. Commit the staged changes with a message (git commit)
4. Push your commits to a remote server like GitHub (git push)

Starting a project

Create a new repo from scratch:

mkdir my-project
cd my-project
git init

Clone an existing repo from GitHub:

git clone https://github.com/username/repo-name.git
cd repo-name

The daily workflow

Check what's changed

git status

Shows which files are modified, staged, or untracked. Run this often – it's your dashboard.

git diff

Shows the exact lines that changed in modified files.

Stage changes

git add file.txt

Stages a specific file. To stage everything:

git add .

Staging is like putting items in a box before shipping. You choose exactly what goes into each commit.

Commit

git commit -m "Add user login form"

Saves the staged changes as a snapshot with a message describing what you did. Write messages that explain why, not just what – "Fix login timeout on slow connections" is better than "Update login.js".

Push to a remote

git push

Sends your commits to the remote server (GitHub, GitLab, etc.) so others can see them.

Pull changes from others

git pull

Downloads and merges changes that others pushed to the remote. Do this before starting work to make sure you're up to date.

View history

git log

Shows the commit history. For a cleaner view:

git log --oneline

Branching

Branches let you work on features in isolation without affecting the main codebase.

Create and switch to a new branch:

git switch -c feature-login

This creates a branch called feature-login and switches to it. (Older tutorials use git checkout -b – it does the same thing.)

Switch between branches:

git switch main
git switch feature-login

Merge a branch back into main:

git switch main
git merge feature-login

Delete a branch after merging:

git branch -d feature-login

List all branches:

git branch

.gitignore

A .gitignore file tells Git which files to ignore – things that shouldn't be tracked like build output, secrets, and editor settings.

Create a .gitignore file in your project root:

node_modules/
.env
dist/
.DS_Store
*.log

Common patterns:

• node_modules/ – dependency folders (they're reinstalled from package.json)
• .env – environment variables and secrets (never commit these)
• dist/ or build/ – compiled output
• .DS_Store – macOS folder metadata
• *.log – log files

Remote hosting (GitHub / GitLab)

Git is local by default. To share your code, push it to a remote host.

SSH vs HTTPS

When cloning or pushing, you choose between two protocols:

• HTTPS: Uses your username and a personal access token. Easier to set up initially
• SSH: Uses SSH keys for authentication. More convenient long-term since you don't need to enter credentials each time

To switch a repo from HTTPS to SSH:

git remote set-url origin [email protected]:username/repo-name.git

The pull request workflow

This is how most teams collaborate:

1. Create a branch: git switch -c fix-bug-123
2. Make your changes and commit them
3. Push the branch: git push -u origin fix-bug-123
4. Open a pull request (PR) on GitHub – this is a request to merge your branch into main
5. Team members review the code and suggest changes
6. Once approved, merge the PR on GitHub
7. Pull the updated main branch locally: git switch main && git pull

Recovery commands

Stash changes temporarily

When you need to switch branches but aren't ready to commit:

git stash

Your changes are saved and the working directory is clean. To bring them back:

git stash pop

Undo changes to a file

Discard all changes to a specific file (reverts to the last commit):

git checkout – file.txt

Or with the newer syntax:

git restore file.txt

Undo the last commit (keep the changes)

git reset --soft HEAD~1

The commit is removed but your changes stay staged, so you can re-commit them.

Undo the last commit (discard everything)

git reset --hard HEAD~1

This removes the commit and all its changes. Use this carefully – it's destructive.

The 10 commands you'll use daily

1. git status – what's changed?
2. git add . – stage everything
3. git commit -m "message" – save a snapshot
4. git push – send to remote
5. git pull – get latest changes
6. git switch -c branch-name – new branch
7. git switch main – go back to main
8. git merge branch-name – merge a branch
9. git log --oneline – see history
10. git diff – see what changed