Part 5 of 5 · Beginner's Handbook

Tips & Tricks

You've got the fundamentals. This part is a grab bag of things that save real time once the basics are automatic — shortcuts, cleanup tools, and a peek at automation.

New here? This part assumes you're comfortable with the everyday commit/push cycle from Part 1. Each trick below is independent, so feel free to skip around.

01 Git Aliases — Shorten Your Commands

Tired of typing git status fifty times a day? Give it a shortcut:

terminal
$git config --global alias.st status
$git config --global alias.co checkout
$git config --global alias.br branch
$git config --global alias.cm "commit -m"

Now git st, git co main, and git cm "message" all work exactly like the full commands.

02 Useful Global Settings

terminal
# set your default editor for commit messages
$git config --global core.editor "code --wait"
# always create main (not master) on git init
$git config --global init.defaultBranch main
# keep pull history simple by rebasing instead of merge commits
$git config --global pull.rebase true
# pretty colored output everywhere
$git config --global color.ui auto

All of these live in a plain text file at ~/.gitconfig you can also just open and edit directly.

03 Stashing — Shelve Work Without Committing

Say you're mid-change and suddenly need to switch branches to fix something urgent, but you're not ready to commit. git stash tucks your uncommitted changes away so your working directory is clean again:

terminal
$git stash
Saved working directory and index state WIP on feature-x
# ...switch branches, fix the urgent thing, come back...
$git stash list
$git stash pop

git stash pop re-applies your changes and removes them from the stash list. Use git stash apply instead if you want to re-apply without removing it, in case you need the same stash on another branch too.

04 Interactive Rebase — Clean Up History Before Pushing

Made three messy "wip" commits in a row and want to squash them into one clean commit before opening a PR? Interactive rebase lets you rewrite recent, not-yet-pushed history:

terminal
$git rebase -i HEAD~3

This opens a list of your last three commits in your editor, each prefixed with pick. Change the word next to any commit you want to fold into the one above to squash (or the shorthand s), save, and Git combines them and lets you write a single clean commit message — the same idea as squash-merging a pull request (see Part 3), just done locally before you even push.

Golden rule: only rebase commits you haven't pushed yet, or that you're certain no one else has pulled. Rebasing shared history rewrites it, which causes real headaches for anyone who already has the old version.

05 Cherry-Picking a Single Commit

Need just one specific commit from another branch, without merging everything else from it? Grab its commit hash and cherry-pick it onto your current branch:

terminal
$git log other-branch --oneline
a1b2c3d fix off-by-one error in pagination
$git cherry-pick a1b2c3d

Common use case: a hotfix was committed on a feature branch by mistake, and you need it on main right now without waiting for the whole feature to be ready.

06 Log & Blame Tricks

terminal
# one line per commit, easy to scan
$git log --oneline
# a visual branch/merge graph in the terminal
$git log --oneline --graph --all
# who last touched each line of a file, and in which commit
$git blame filename.js

07 GitHub Search & Keyboard Shortcuts

A few things that speed up browsing GitHub itself, not the terminal:

  • Press t on any repo page to fuzzy-search and jump straight to a file by name.
  • Press . (period) on any repo page to open it in a full web-based VS Code editor, right in the browser.
  • Press / anywhere on GitHub to jump to the search bar.
  • In search, filename:package.json org:your-org style qualifiers narrow results — GitHub's search supports dozens of these (is:pr, is:open, author:username, language:python, and more).

08 A Taste of GitHub Actions

GitHub Actions runs automated steps every time something happens in your repo — most commonly, running tests automatically on every push or pull request (these are the "status checks" mentioned in Part 3). It's a big topic on its own, but the entry point is small: a YAML file — a plain-text format that uses indentation to show structure, similar to how Python uses indentation instead of curly braces — placed in a specific folder.

.github/workflows/test.yml
name: Run Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

This particular example assumes a Node.js project — swap npm install and npm test for whatever commands actually install and test your own project. Commit the file and push it — GitHub picks it up automatically and runs it on every future push, showing a green check or red cross right on your commits and pull requests. Combined with the branch protection rule from Part 3 that requires status checks to pass, this is how teams stop broken code from being merged. You can also check on a run without leaving the terminal using the GitHub CLI from Part 2 — see the cheat sheet below.

09 Tips & Tricks Cheat Sheet

git stash / git stash pop Shelve uncommitted changes, then bring them back later
git rebase -i HEAD~n Interactively edit, squash, or reorder your last n commits
git cherry-pick <hash> Apply one specific commit from another branch onto the current one
git log --oneline --graph --all Visualize branch and merge history in the terminal
git blame <file> See who last changed each line, and in which commit
git config --global alias.<name> "<command>" Create a shortcut for any Git command
gh run list See recent GitHub Actions runs for the current repo, from the terminal

That's the whole handbook. Head back to the home page any time you need to jump to a different chapter.