Logo of the site

My cheatsheet

GitHub cheatsheet

This is a quick reference cheat sheet for understanding and writing GitHub.

# Getting started

Introduction

Git is the industry-standard version control system that allows multiple developers to work on a project simultaneously by tracking changes and coordinating work.

# Git Flow

Branching Basics

Check which branch you're on:

git branch

Create a new branch:

git branch new_branch

Switch to it:

git checkout branch_name

Merge & Conflicts

To merge a branch into master:

git merge branch_name

If no new commits exist on master, this is a fast-forward merge.

If a commit on master modifies the same lines as the branch, a merge conflict occurs:

CONFLICT (content): Merge conflict in resumé.txt
Automatic merge failed; fix conflicts and then commit the result.

Delete branches

After merging:

git branch -d branch_name

Force delete if not merged:

git branch -D branch_name

Cloning & Remotes

Clone a remote repo:

git clone remote_location clone_name

remote_location can be a URL or local path.

See remote connections:

git remote -v

Download remote changes (no merge):

git fetch

Merge remote branch into local:

git merge origin/master

Push to Remote

Push local branch to origin:

git push origin <branch_name>

.gitignore

Ignore files from being staged/committed.

# Windows OS file
thumbs.db

# macOS OS file
.DS_Store

# Dependency folders
node_modules/

# Configs
.env

Use patterns. Comments start with #. More at: git-scm.com

Fork

Create a copy of a GitHub project to work on independently.

Repository template

Blueprint repo to quickly generate new projects with same structure/configs. Useful for teams.

Rebase

Rewrites the history of a feature branch to place it "on top" of another (usually main). Keeps history linear and avoids extra merge commits.

Use Case

You create a feature branch new_feature. Meanwhile, a teammate fixes a bug in quick_fix and merges it into main.

Now main and new_feature have diverged.

To bring changes from main into your feature branch without polluting the history:

git checkout new_feature
git rebase main

What Happens?

  • Commits from main are applied first.
  • Then your new_feature commits are "replayed" one by one.
  • The base of your branch becomes the tip of main.
before rebase schema after rebase schema

Benefits

  • Cleaner, linear history
  • No unnecessary merge commits
  • Easier to follow changes in git log or git graph

Merge vs Rebase

  • Merge: Preserves exact history, includes merge commits.
  • Rebase: Rewrites history, applies changes in order.
merge vs rebase schema

Risks of Rebase

  • It’s a destructive operation: old commits are replaced with new ones.
  • Do not rebase after pushing to a shared repo (can break other clones).
  • Can cause multiple conflict resolutions (once per commit replayed).

Best Practices

  • Use rebase only on local or private branches.
  • Squash commits when possible to simplify history.
  • Rebase frequently to avoid big conflict batches.

# Github repository

README conventions

A high‑quality README showcases your project and helps others (and your future self) understand, install, and contribute to it. Keep the README concise, up‑to‑date, and self‑explanatory to leave a professional impression.

  • Project Title The name of your project, prominently displayed.
  • Description Explain the project’s purpose, motivations, problem(s) solved, and key learnings.
  • Features List and, if possible, illustrate unique or core features (screenshots/gifs welcome).
  • How to Use Step‑by‑step install and usage instructions, including requirements.
  • Technologies Enumerate frameworks, libraries, and tools used, with their roles.
  • Collaborators Credit contributors with links to their GitHub profiles.
  • License Specify the license so others know usage and contribution terms.

# GitHub Actions & Automated Testing

What is GitHub Actions?

GitHub Actions is a feature for creating automated workflows triggered by repository events like push, pull request, or issue creation. Workflows are defined in YAML files and run in GitHub-hosted containers.

When to Use GitHub Actions

  • CI/CD: Automatically build, test, and deploy code.
  • Code Reviews: Run linters or security checks on PRs.
  • Notifications: Send Slack/Teams/email alerts on events.
  • Dependency Updates: Automate package updates.
  • Issue Labeling: Auto-assign labels or contributors.

Find templates in the Actions Marketplace.

Workflow Components

  • Events: Triggers (e.g. push, pull_request), set using on
  • Jobs: Groups of steps, set with jobs
  • Runners: OS environment, defined via runs-on
  • Steps: Individual commands inside a job
  • Actions: Prebuilt or custom logic via uses or run

Tutorial 1: Automated Testing

Create: .github/workflows/unittests.yaml

name: Continuous Integration

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: 3.12.0
          architecture: x64
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run Tests
        run: python -m pytest

This workflow runs on every push. It:

  • Checks out the current Git branch
  • Sets up Python 3.12 on Ubuntu
  • Installs project dependencies
  • Runs unit tests with pytest

After pushing, go to the Actions tab to view logs. A green check appears if tests pass; if not, the workflow fails and blocks pull request merging.

Tutorial 2: Basic Workflow Template

File: .github/workflows/basic.yml

# This is a basic workflow to help you get started with Actions
name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v4

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

This workflow is triggered on push or pull request to main, or manually from GitHub UI. It:

  • Checks out code using actions/checkout@v4
  • Prints "Hello, world!" in one step
  • Prints a multi-line message in another step