The Git cheat sheet · Arlou A. Beloria

Setup and connect Once

git config --global user.name "Your Name"

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

# same email as GitHub

git config --global init.defaultBranch main

git config --global pull.rebase false

# pull = merge

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

# Enter three times

cat ~/.ssh/id_ed25519.pub

# paste at GitHub → Settings → SSH keys

ssh -T git@github.com

# "Hi username!" = connected

gh auth login

# or let the GitHub CLI do all of it

git remote set-url origin git@github.com:you/repo.git

# swap HTTPS for SSH

Windows: run everything in Git Bash, not PowerShell. No SSH on this network? Clone the https:// URL and paste a fine-grained Personal Access Token where it asks for a password.

Daily loop Every day

git status

# what changed

git diff

# see the changes

git add .

# stage (or name one file)

git commit -m "message"

# snapshot

git push

# send

git pull

# receive

git log --oneline

# history

add puts items in the cart, commit checks out. Nothing is saved to history until you commit.

Start or join a repo Per project

git init

# new repo here

git remote add origin git@github.com:user/repo.git

git push -u origin main

# first push

git clone git@github.com:user/repo.git

# copy an existing repo

git remote -v

# where do I push?

git remote add upstream git@github.com:owner/repo.git

git pull upstream main

# get the original's updates

Fork copies a repo to your GitHub account. Clone downloads it to your laptop. Fork once, clone as often as you like.

New repo on GitHub: + → New repository → name it → Public → leave Configuration untouched (README off, no .gitignore, no license) → Create. Anything switched on there is a commit your laptop lacks, and your first push is rejected.

Someone else's repo Every pull request

git switch main

# 1. start from a clean main

git fetch upstream && git merge upstream/main

# 2. sync before you branch

git push

# 3. update your fork too

git switch -c feature/the-thing

# 4. type/what, one topic

git commit -m "Add the thing"

# 5. imperative, under 50 chars

git push -u origin feature/the-thing

# 6. then open the pull request

Title · what and why · Closes #12

# 7. read your own diff first

git switch main && git pull

# 8. after it merges

git branch -d feature/the-thing

# 9. tidy up

Squash if you are unsure which merge button to press: one pull request becomes one commit on main. GitLab calls the same thing a merge request.

Naming things Branches and commits

type/short-description

# branch: lowercase, hyphens, one topic

feature/ fix/ docs/ chore/

# the usual types · add the issue number if there is one

type(scope): short description

# conventional commit · scope optional

feat: add Alex to attendees

# new feature = minor version

fix(pages): serve index.html from the root

# bug fix = patch version

feat!: drop support for Node 18

# ! or a BREAKING CHANGE: footer = major version

docs style refactor perf test build ci chore

# the other types

Imperative, lowercase after the colon, no full stop, first line under 72 characters. Match the repo: read git log --oneline and git branch -r before your first commit and use what they use. conventionalcommits.org

Branches and undo When needed

git switch -c name

# new branch

git switch main

# go back

git merge name

# from main

git branch

# list · -d name deletes

git restore file

# undo unstaged edits

git reset --soft HEAD~1

# uncommit, keep work

git reset --hard HEAD~1

# uncommit, discard work

git revert HEAD

# undo a pushed commit

git reflog

# everything you ever did

git blame file

# who last touched each line

restore for files, reset for commits only you have, revert for commits others may have pulled. Never reset --hard on a shared branch.

The merge strategy Which button

merge commit main: M ── ── ── merge

# every commit kept, plus one more

squash main: M ── ABC

# one pull request, one commit

rebase main: M ── A' B' C'

# linear, kept, new IDs

git merge --squash feature/thing

# the same, done yourself

git rebase main

# replay your commits onto main

git rebase -i HEAD~3

# reword, squash or drop

git rebase --abort

# back out mid-rebase

Unsure? Squash. One pull request becomes one line in the log. Never rebase a branch others have pulled: it rewrites history they already hold. Use git revert there instead.

Merge conflicts When it breaks

git status

# which files are conflicted

<<<<<<< HEAD

# your version starts here

=======

# theirs starts here

>>>>>>> upstream/main

# and ends here

git add the-file

# staging it means resolved

git commit

# no -m; Git wrote the message

git merge --abort

# bail out, nothing lost

Keep the text you want, delete the three marker lines. Often you keep both sides. Prevention: sync before you branch, and keep branches short.

Markdown README.md

# Heading 1

# biggest heading

## Heading 2

# section heading

**bold** and *italic*

- item

# bulleted list

1. item

# numbered list

[text](https://url)

# link

![alt text](image.png)

# image

`code`

# inline code

---

# horizontal rule

A repo named exactly your-username makes its README your GitHub profile page.

Ship a site GitHub Pages

git clone git@github.com:your-username/portfolio.git

# your fork, renamed

code .

# edit index.html

git add . && git commit -m "Make it mine"

git push

# Pages rebuilds on its own

Settings → Pages → Deploy from a branch → main / root → Save. Live in about a minute at your-username.github.io/portfolio. Keep paths relative (href="style.css").

Keep going Resources

Workshop repo: github.com/Arlovzki/git-github-101
Portfolio starter: github.com/Arlovzki/portfolio-starter
Practice: learngitbranching.js.org
When something goes wrong: ohshitgit.com
Read: git-scm.com/book (Pro Git, free)
Commit convention: conventionalcommits.org
Markdown: markdownguide.org/cheat-sheet
Profile README generator: rahuldkjain.github.io/github-profile-readme-generator