Git and GitHub

What is Git?

Git is a tool that keeps track of every change you make to your files over time. It is called a version control system. Think of it like a save button that remembers every single version of your project, so you can always go back to an older version if something breaks.

Git runs on your own computer. It does not need the internet to work, because it saves everything in a hidden folder called .git inside your project.

Note

Git and GitHub are not the same thing. Git is the tool that tracks changes on your computer. GitHub is a website that stores your Git projects online, so you can share them and work with other people.

Why Use Git?

Keeps history

Every change you save is stored. You can look back at old versions or undo mistakes any time.

Safe experiments

You can try new ideas in a separate “branch” without touching your main, working code.

Works with a team

Many people can work on the same project at the same time without overwriting each other’s work.

Backup and sharing

When you push your code to GitHub, it is safely stored online and easy to share with others.

What is GitHub?

GitHub is a website where you can store your Git projects (called repositories, or “repos” for short) online. It adds extra features on top of Git, like:

• A place to see and review other people’s code changes (pull requests)
• A way to track bugs and to-do items (issues)
• Tools to automate testing and deployment (GitHub Actions)
• A way to work together with a whole team, safely

Tip

There are other websites like GitHub, such as GitLab and Bitbucket. They all use Git underneath, but each one has its own extra features and look.

How Git Actually Works

Git saves your project as a series of snapshots (called commits), not just a list of changes. Each commit points back to the commit before it, forming a chain of history.

graph LR A["Working Directory - your files"] -->|git add| B["Staging Area - ready to save"] B -->|git commit| C["Local Repository - saved history"] C -->|git push| D["Remote Repository - GitHub"] D -->|git pull / git fetch| C

• Working Directory: The actual files you see and edit on your computer.
• Staging Area: A waiting area where you choose exactly which changes you want to save next.
• Local Repository: The saved history of commits, stored in the .git folder on your computer.
• Remote Repository: A copy of your project stored somewhere else, like on GitHub.

Getting Started with Git

1. Install Git: Download it from the official Git website and follow the steps for your computer (Windows, macOS, or Linux).

2. Check that it installed correctly:

   git --version

3. Set up your name and email: Git attaches your name and email to every commit you make, so people know who made each change.

   git config --global user.name "Your Name"
   git config --global user.email "you@example.com"

   The --global flag means these settings apply to every project on your computer. If you want different settings for just one project, run the same commands without --global while inside that project’s folder.

4. Check your settings any time:

   git config --list

Tip

You can also set your favourite text editor for Git to use, for example:

git config --global core.editor "code --wait"

This tells Git to open VS Code whenever it needs you to type a message.

Creating and Cloning Repositories

Starting a New Project

git init

This turns the current folder into a Git repository by creating a hidden .git folder. From now on, Git will start tracking changes in this folder.

Copying an Existing Project (Clone)

If a project already exists on GitHub, you can download a full copy, including all its history, using git clone.

git clone https://github.com/username/repository.git

This creates a new folder on your computer with the same name as the repository, and downloads every file and every past commit.

Note

git init is for starting a brand-new project from nothing. git clone is for downloading a project that already exists somewhere else, like on GitHub.

The Basic Git Workflow

This is the everyday flow you will use again and again: change a file, stage it, then commit it.

graph TD A["Edit files"] --> B["git status - see what changed"] B --> C["git add - stage the changes"] C --> D["git commit - save a snapshot"] D --> E["git push - upload to GitHub"]

1. git status - Shows you which files have changed, which are staged, and which are not tracked yet.

git status

2. git add <file> - Moves a file into the staging area, meaning “I want to save this change in my next commit.”

git add index.html
# stage just one file

git add .
# stage every changed file in the current folder

3. git commit -m "message" - Saves a snapshot of everything in the staging area, along with a short message describing what changed.

git commit -m "Add homepage layout"

Tip

Write clear, short commit messages that explain what changed and why, like "Fix login button not responding on mobile". This helps you and your team understand the project’s history later.

4. git log - Shows the history of commits, from newest to oldest.

git log
# shows full details for every commit

git log --oneline
# shows a short, one-line summary for each commit

5. git diff - Shows the exact lines that changed, before you stage them.

git diff
# shows changes not yet staged

git diff --staged
# shows changes that are staged, ready to commit

Undoing Changes

Mistakes happen. Git gives you several ways to undo them, depending on how far you’ve already gone.

Not staged yet

git checkout -- <file>
# or, in newer Git versions:
git restore <file>

Throws away your unsaved changes in that file and brings back the last committed version.

Already staged

git reset <file>
# or, in newer Git versions:
git restore --staged <file>

Removes the file from the staging area, but keeps your changes in the working directory.

Already committed

git revert <commit id>

Creates a new commit that undoes the changes from an older commit. This is the safest way to undo something that has already been pushed and shared with others.

Rewrite history (careful!)

git reset --hard <commit id>

Moves your branch back to an older commit and throws away everything after it. Use this only on commits that you have not shared with anyone else yet.

Danger

git reset --hard permanently deletes your uncommitted changes and any commits after the one you reset to. Only use it when you are sure, and never use it on commits that other people have already pulled.

Branches

A branch is like a separate copy of your project where you can try new things without touching your main, working code. The default branch is usually called main (older projects sometimes call it master).

gitGraph commit id: "Initial commit" commit id: "Add homepage" branch feature-login checkout feature-login commit id: "Add login form" commit id: "Add validation" checkout main commit id: "Fix typo" merge feature-login commit id: "Release v1.0"

1. git branch - Lists every branch in your project, and shows which one you’re currently on.

git branch

2. git branch <name> - Creates a new branch, but does not switch to it yet.

git branch feature-login

3. git checkout <name> or git switch <name> - Moves you onto a different branch.

git checkout feature-login
# or, in newer Git versions:
git switch feature-login

4. Create and switch in one step:

git checkout -b feature-login
# or
git switch -c feature-login

5. git branch -d <name> - Deletes a branch that has already been merged.

git branch -d feature-login

Caution

If a branch has changes that were never merged, git branch -d will refuse to delete it and warn you. If you’re sure you want to delete it anyway, use git branch -D (capital D) - but be careful, because this can permanently lose work.

Merging and Rebasing

Once your work on a branch is ready, you need to bring it back into main. There are two common ways to do this.

Merge

git checkout main
git merge feature-login

Combines the two branches together and creates a new “merge commit” that joins their histories. This keeps the full history of both branches, exactly as it happened.

Rebase

git checkout feature-login
git rebase main

Takes your branch’s commits and replays them on top of the latest main, making the history look like a single straight line, as if you had started your branch just now.

Caution

Rebase rewrites commit history. Never rebase commits that you have already pushed and that other people might be using, since it can cause confusing conflicts for them.

Merge Conflicts

Sometimes Git cannot automatically combine two changes, because they both edited the same lines. This is called a merge conflict. Git will pause and mark the conflicting area in the file, like this:

<<<<<<< HEAD
This is the version from your current branch.
=======
This is the version from the branch you're merging in.
>>>>>>> feature-login

1. Open the file and look for the <<<<<<<, =======, and >>>>>>> markers.

2. Edit the file so it has the final, correct content, and remove the marker lines.

3. Stage the fixed file:

   git add <file>

4. Finish the merge with a commit:

   git commit

Working with Remotes (GitHub)

A remote is simply a saved link to an online copy of your repository, like the one on GitHub.

1. git remote add <name> <url> - Connects your local project to an online repository.

git remote add origin https://github.com/username/repository.git

origin is just a nickname - almost everyone uses origin as the standard name for the main remote.

2. git remote -v - Shows every remote connected to your project, and their URLs.

git remote -v

3. git push - Uploads your commits to the remote repository.

git push origin main
# uploads the "main" branch to the "origin" remote

git push -u origin main
# same as above, but also remembers this pairing,
# so next time you can just type "git push"

4. git pull - Downloads new commits from the remote and combines them into your current branch.

git pull origin main

git pull is really just git fetch followed by git merge, done in one step.

5. git fetch - Downloads new commits from the remote, but does not merge them into your files yet.

git fetch origin

Tip

Use git fetch when you want to see what changed on GitHub first, before deciding to merge it into your own work. Use git pull when you just want to update right away.

Connecting to GitHub with SSH

Using SSH keys lets you connect to GitHub without typing your username and password every time.

1. Create an SSH key (skip this if you already have one):

   ssh-keygen -t ed25519 -C "you@example.com"

2. Copy your public key:

   cat ~/.ssh/id_ed25519.pub

3. Add it to GitHub: Go to GitHub -> Settings -> SSH and GPG keys -> New SSH key, and paste the key you copied.

4. Test the connection:

   ssh -T git@github.com

5. Clone repositories using the SSH link instead of the HTTPS one:

   git clone git@github.com:username/repository.git

.gitignore

A .gitignore file tells Git which files and folders to never track or save. This is useful for things like passwords, build files, or huge folders like node_modules that don’t need to be saved in your project’s history.

# Ignore dependency folders
node_modules/
venv/

# Ignore environment and secret files
.env
.env.local

# Ignore build output
dist/
build/

# Ignore log files
*.log

# Ignore OS and editor files
.DS_Store
.vscode/

Caution

.gitignore only stops Git from tracking new files. If a file was already committed before you added it to .gitignore, you need to remove it from Git’s tracking on purpose:

git rm --cached <file>

This removes the file from Git’s tracking, but keeps it safely on your computer.

Stashing Changes

Sometimes you need to quickly switch to a different branch, but you’re not ready to commit what you’re working on yet. git stash lets you save your unfinished changes for later, without committing them.

git stash
# saves your uncommitted changes and cleans your working directory

git stash list
# shows every stash you've saved

git stash pop
# brings back the most recent stash, and removes it from the list

git stash apply
# brings back the most recent stash, but keeps it in the list too

Tip

Stashing is perfect for moments like: “I need to quickly fix a bug on another branch, but I’m not done with what I’m doing right now.”

Tags

A tag marks a specific commit as important, usually to label a release version, like v1.0.0.

git tag v1.0.0
# creates a tag on the current commit

git tag
# lists every tag in the project

git push origin v1.0.0
# uploads a single tag to GitHub

git push origin --tags
# uploads every tag to GitHub

GitHub Repositories, Forks, and Pull Requests

Repositories

A repository (or “repo”) is a project’s home on GitHub. It holds your code, its full history, and extra tools like issues and pull requests.

Forking

A fork is your own personal copy of someone else’s repository, made under your own GitHub account. You can freely make changes in your fork without affecting the original project.

The Typical Open-Source Workflow

graph TD A["Fork the repository"] --> B["Clone your fork to your computer"] B --> C["Create a new branch"] C --> D["Make changes and commit"] D --> E["Push your branch to your fork"] E --> F["Open a Pull Request to the original repo"] F --> G["Owner reviews and merges it"]

Pull Requests (PRs)

A pull request is a request asking the project owner to pull your changes into their repository. It shows exactly what you changed, and lets other people leave comments, ask questions, or request changes before it gets merged.

1. Push your branch to GitHub:

   git push origin feature-login

2. Go to the repository on GitHub. You’ll usually see a button to “Compare & pull request”.

3. Write a clear title and description explaining what you changed and why.

4. Submit the pull request, and wait for a review.

5. If changes are requested, make them, commit, and push again - the pull request updates automatically.

6. Once approved, the pull request gets merged into the main branch.

Tip

Keep your pull requests small and focused on one thing. Small pull requests are easier and faster for other people to review.

Issues

Issues are GitHub’s way of tracking bugs, feature requests, and to-do items for a project. Anyone with access can open an issue, discuss it in the comments, and link it to the pull request that fixes it.

Branch Protection

Project owners can set up branch protection rules on important branches like main, so that:

• Changes can only come in through a reviewed pull request, not a direct push.
• At least one (or more) other people must approve the pull request first.
• Automated checks (like tests) must pass before merging is even allowed.

Note

Branch protection is a settings feature on GitHub itself, not a Git command. You set it up from the repository’s Settings -> Branches page.

GitHub Actions

GitHub Actions is GitHub’s built-in tool for automating tasks, like running tests, checking code style, or deploying your app, every time something happens in your repository (like a push or a pull request). This is often called CI/CD (Continuous Integration / Continuous Deployment).

Continuous Integration (CI)

Automatically test and check your code every time someone pushes changes, so bugs get caught early.

Continuous Deployment (CD)

Automatically deploy your app to a server or a website once your code passes all its checks.

Automation

Automate almost anything - labeling issues, sending notifications, running scheduled jobs, and more.

How GitHub Actions Works

graph TD A["Event happens - e.g. push, pull request"] --> B["Workflow file is triggered - .github/workflows/*.yml"] B --> C["Job 1 runs on a runner - a fresh virtual machine"] B --> D["Job 2 runs on a runner"] C --> E["Steps run in order inside the job"] D --> F["Steps run in order inside the job"]

• Workflow: A full automation process, written as a YAML file, stored in the .github/workflows/ folder of your repository.
• Event: Something that starts (triggers) a workflow, like a push, a pull request, or a schedule.
• Job: A set of steps that run together on the same runner (virtual machine). A workflow can have more than one job, and by default they run at the same time (in parallel).
• Step: A single task inside a job, like running a command or using someone else’s pre-built action.
• Action: A reusable piece of automation that someone else already built, which you can just plug into your workflow (for example, an action that sets up Node.js for you).
• Runner: The actual computer (virtual machine) that runs your jobs. GitHub provides free runners for Linux, Windows, and macOS.

Where Workflow Files Go

Workflow files must be placed in this exact folder in your repository:

.github/workflows/

Each .yml file inside this folder is its own separate workflow.

A Simple Example Workflow

This example runs tests automatically every time someone pushes code, or opens a pull request, to the main branch.

# .github/workflows/ci.yml
name: Run Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Check out the code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

Breaking Down the Workflow File

• name: Run Tests - A friendly name for the workflow, shown on GitHub’s “Actions” tab.
• on: - Lists the events that trigger this workflow. Here, it runs on a push or a pull request to main.
• jobs: - Lists the jobs in this workflow. Here there is one job, named test.
• runs-on: ubuntu-latest - Says which type of virtual machine (runner) this job should use.
• steps: - The list of tasks this job runs, in order, from top to bottom.
• uses: - Runs a pre-built action made by GitHub or the community (here, actions/checkout downloads your repository’s code onto the runner, and actions/setup-node installs Node.js).
• run: - Runs a plain command line instruction, just like you would type in a terminal.

Tip

actions/checkout@v4 is used in almost every workflow, because without it, your job’s runner starts completely empty - it doesn’t have your repository’s code yet.

Common Triggers (on:)

push

on:
  push:
    branches: [main]

Runs the workflow every time someone pushes commits to the listed branch.

pull_request

on:
  pull_request:
    branches: [main]

Runs the workflow whenever a pull request is opened or updated, targeting the listed branch.

schedule

on:
  schedule:
    - cron: "0 0 * * *"

Runs the workflow on a timer, using cron syntax. This example runs once a day, at midnight.

workflow_dispatch

on:
  workflow_dispatch:

Adds a manual “Run workflow” button on GitHub, so you can start the workflow yourself, whenever you want.

Using Secrets

Never write passwords, API keys, or tokens directly inside a workflow file, since anyone who can see your repository could read them. Instead, store them as secrets.

1. Go to your repository on GitHub.

2. Open Settings -> Secrets and variables -> Actions.

3. Click New repository secret, give it a name (like API_KEY), and paste in the value.

4. Use it in your workflow like this:

   steps:
     - name: Deploy app
       run: ./deploy.sh
       env:
         API_KEY: ${{ secrets.API_KEY }}

Danger

Never echo a secret to the log, and never hardcode a real secret value into a workflow file, even for testing. GitHub Actions logs can sometimes be seen by other people with access to the repository.

Matrix Builds

A matrix lets you run the same job multiple times, automatically, with different settings each time - for example, testing your app on several versions of Node.js at once.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm test

This example runs the whole job three separate times, once each for Node.js 18, 20, and 22, all at the same time.

Jobs That Depend on Each Other

By default, jobs run at the same time (in parallel). Use needs to make one job wait for another to finish first.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Building the app..."

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying the app..."

Here, the deploy job will always wait for build to finish successfully before it starts.

Artifacts

Artifacts let you save files created during a job (like a build output) and share them with other jobs, or download them later from GitHub.

steps:
  - name: Build the app
    run: npm run build

  - name: Upload build output
    uses: actions/upload-artifact@v4
    with:
      name: build-output
      path: dist/

A Simple Example: Deploying on Every Merge to Main

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm install

      - name: Build the app
        run: npm run build

      - name: Deploy
        run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Note

This is just an example. The actual deploy step depends on where you’re hosting your app - many hosting providers (like Vercel, Netlify, or AWS) have their own ready-made GitHub Actions you can use instead of writing your own deploy script.

Quick Command Cheat Sheet

Task	Command
Start tracking a new project	git init
Copy an existing project	git clone <url>
Check what changed	git status
Stage changes	git add <file> or git add .
Save a snapshot	git commit -m "message"
See history	git log --oneline
Create a branch	git branch <name>
Switch branches	git switch <name>
Create and switch at once	git switch -c <name>
Combine branches	git merge <branch>
Upload to GitHub	git push origin <branch>
Download from GitHub	git pull origin <branch>
Save unfinished work for later	git stash
Undo an unstaged change	git restore <file>
Undo a committed change (safely)	git revert <commit id>

Keep this handy

You don’t need to remember every command by heart. Keep this table nearby while you’re learning, and the commands you use often will stick with you naturally.