Git & CI/CD
Git & CI/CD
Day 4 · From commit to production
Two halves of one loop. Git is how your team communicates intent through code; CI/CD is how that code becomes a running thing customers can use - automatically, repeatably, and without anyone SSHing into a box at midnight. You can't have a trustworthy pipeline on top of a messy history, and a clean history is wasted if shipping is still manual and scary.
The instinct we're training: the merge button is the deploy button. When you press it, a reviewed change becomes production. Everything in this chapter exists to make that one click safe.
How this chapter is structured
This chapter is one day, split into two tight sub-chapters. Do them in order - the second assumes the first.
- Git - the three trees, branching and rebasing, rewriting history safely, recovering from disaster, and the PR craft we expect on every change.
- CI/CD - GitHub Actions, the standard install→lint→typecheck→test→build→deploy pipeline, secrets via OIDC, preview deploys, deployment strategies, and the one capability that matters most: rollback.
Each sub-chapter is a self-contained primer with its own hands-on checkpoints. Your buddy reviews both before you mark this chapter complete. The grid below takes you there.
Sub-chapter map
| # | Sub-chapter | What you'll be able to do |
|---|---|---|
| 1 | Git | Make a reviewable PR, rebase cleanly, and recover anything with reflog |
| 2 | CI/CD | Wire a pipeline that blocks broken merges and can roll back in one click |
Why these two together
Git without CI is a team agreeing on a process no machine enforces. CI without Git discipline is automation papering over chaos - a green pipeline on a branch nobody can review. Put them together and you get the Welzin default: short-lived branches, small PRs, a pipeline that gates the merge, and a deploy you trust enough to do on a Friday.
The skills compound. A clean, rebased branch makes CI fast and its failures legible. A pipeline that runs on every PR makes you brave enough to refactor. By the end of the day you should be able to take a feature from git switch -c to a live preview URL to production - and back out again if it misbehaves.
Welzin opinion: If you're afraid to deploy, the problem is almost never the code - it's that your history is unreviewable or your pipeline has no rollback. Fix those two and shipping stops being an event.