What you will achieve

You will build a release pipeline that turns a Git tag into a deployed artefact - signed, tested, versioned, and published. The pattern works for npm packages, Docker images, mobile apps, and binary distributions. By the end, you will tag a commit and watch the release happen.

The contract

The pipeline's contract:

What you will achieve

You will deliberately mess up a rebase, then recover using the reflog and ORIG_HEAD. The recovery patterns work for any rewrite gone wrong - botched interactive rebase, accidental drop, mid-rebase confusion.

What you will achieve

You will configure a code review workflow that scales from three to thirty contributors: branch protection, CODEOWNERS, PR templates, automated checks, and conventions for reviewers and authors. By the end, the repo enforces a process that catches bugs early and onboards new contributors smoothly.

Step 1: choose a model

The dominant model in 2026 is GitHub Flow:

What you will achieve

You will use git blame and git log together to reconstruct the history of a buggy line, identify when and why a change was made, and find the right person to consult. The same techniques apply to bug-hunting, security incident response, and onboarding.

What you will achieve

You will set up automated version bumping and changelog generation driven by Conventional Commits. Push a feature, get a minor version bump and changelog entry; push a fix, get a patch bump - all without manual intervention.

The mechanism

Tooling reads commit messages following the Conventional Commits format (feat:, fix:, chore:) and decides what kind of release to cut. BREAKING CHANGE: footers trigger major bumps. The result: a strict mapping from commit history to release version.

What you will achieve

You will combine several existing Git repositories into a single monorepo, preserving each repo's history under its own subdirectory. The result: one repo, one CI pipeline, atomic cross-package commits.

Why monorepo

Multi-repo setups make cross-cutting changes hard. Renaming a function exported by a shared library and updating every caller becomes a coordination dance across PRs. In a monorepo, it is one PR. The trade-off: tooling investment and repo-size management.

What you will achieve

You will create a Git worktree to check out a second branch in a different directory while keeping your current work intact. The pattern is invaluable for hotfixes, code review, parallel feature work, and long-running comparisons.

The problem

You are deep in feature/checkout when a teammate pings you about a urgent hotfix on main. Stash, switch, fix, switch back, pop the stash - you have lost five minutes and most of your context. Worktrees keep both branches checked out simultaneously.

What you will achieve

You will configure Git to sign commits and tags using your existing SSH key, set up the allowed-signers file for verification, and integrate with GitHub or GitLab so signatures display as verified.

Why SSH signing

SSH signing landed in Git 2.34 (November 2021). It reuses the SSH key you already use for pushes - no separate GPG key management, no gpg-agent headaches. Modern Git hosts (GitHub, GitLab, Gitea, Forgejo) verify SSH signatures natively.

What you will achieve

You will roll back a problematic release - first by reverting commits to undo the change in the working history, then by re-tagging an earlier version for re-deployment. By the end, you will be able to handle a "we need to undo v2.4.0 right now" incident calmly.

What you will achieve

You will cherry-pick a single commit, a range, and a merge from one branch to another, handling conflicts when they arise. The pattern is essential for back-porting fixes, promoting hotfixes, and rescuing work from abandoned branches.