Git, CI/CD and zero-downtime deploys

01Git fundamentals: commits, branches, merge vs rebase

A commit is a snapshot of the whole project plus a message and a pointer to its parent, so history is a chain of snapshots. A branch is just a movable label pointing at a commit, which is why branches are cheap. When two lines of work need to come together you either merge or rebase. A merge creates a new commit with two parents and keeps history exactly as it happened. A rebase replays your commits on top of the latest main, producing a straight line, but it rewrites those commits with new hashes. The rule: rebase your own local or feature branch to tidy it up, never rebase commits other people have already pulled. Good commits are small and focused, with a message that explains why, not only what.

1git switch -c feature/order-export
2git add -p                       # stage hunks, review as you go
3git commit -m "Add CSV export for orders"
4git fetch origin
5git rebase origin/main           # update your branch, resolve conflicts
6git push --force-with-lease      # safe force-push of your own branch
7git log --oneline --graph -15

02Branching strategies: trunk-based vs GitFlow

Trunk-based development keeps one main branch that is always releasable. Developers work on short-lived branches, ideally merged within a day or two, and hide unfinished features behind feature flags. It minimises painful merges and pairs naturally with continuous deployment. GitFlow uses long-lived develop and main branches plus feature, release and hotfix branches. It suits products with versioned, scheduled releases, such as mobile apps that pass store review or on-premise software where several versions are supported at once. For most web apps, trunk-based with short pull requests wins. Whatever you choose, protect main: require pull requests, passing checks and at least one review, and forbid force-pushes.

• Trunk-based: short branches, feature flags, deploy from main.
• GitFlow: develop + release branches, good for versioned releases.
• Release tags (v1.8.0) mark exactly what went to production.

03Pull requests and code review

A pull request is a proposal to merge a branch, plus a conversation about it. Its job is to catch bugs, share knowledge and keep the codebase consistent, not to show who is senior. Keep pull requests small, ideally under a few hundred lines, because review quality drops sharply with size. The description should say what changed, why, and how it was tested, with screenshots for UI work. Automation should handle style and formatting so humans can focus on logic, data safety, security, naming and missing tests. Reviewers should be specific and kind, and separate blocking issues from suggestions. CODEOWNERS files route changes to the people who know an area, and required status checks stop anything merging while CI is red.

04Continuous integration: a pipeline that runs on every change

Continuous integration means every push and pull request is built and tested automatically in a clean environment. A typical pipeline installs dependencies from the lockfile, runs the linter and type checker, runs unit and feature tests, and builds the production artifact. Order steps from fastest to slowest so most failures appear within a minute or two. Cache dependency downloads between runs. The pipeline must be the same gate for everyone: if it is red, the change does not merge. Below is a minimal GitHub Actions workflow for a Node or Next.js project; GitLab CI, Bitbucket Pipelines and others use very similar ideas with different syntax. Secrets live in the CI provider's secret store, never in the repository.

1name: ci
2on:
3  pull_request:
4  push:
5    branches: [main]
6jobs:
7  check:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v5
11      - uses: actions/setup-node@v5
12        with: { node-version: 24, cache: npm }
13      - run: npm ci
14      - run: npm run lint
15      - run: npx tsc --noEmit
16      - run: npm test
17      - run: npm run build

05Deployment strategies: rolling, blue-green, canary

Continuous delivery means every green build can be deployed with one click; continuous deployment means it is deployed automatically. How you replace the running version matters. A rolling deploy replaces instances one at a time behind a load balancer, so capacity dips slightly but service continues. Blue-green keeps two identical environments: you deploy to the idle one (green), test it, then switch traffic at the load balancer or symlink, and switching back is instant. Canary sends a small share of traffic, say five percent, to the new version, watches error rates and latency, and widens gradually. On a single server, the blue-green idea is usually implemented with release folders and an atomic symlink switch, or with a new container started and health-checked before the proxy is pointed at it.

• Rolling: cheap, gradual, two versions live at once.
• Blue-green: instant switch and instant rollback, needs double capacity briefly.
• Canary: limits blast radius, needs good metrics to judge.

06Zero-downtime deploys for Laravel and Next.js

For Laravel on a VPS, the proven pattern is atomic releases: each deploy goes into a new timestamped folder, shares the .env and storage directory through symlinks, installs dependencies and builds caches there, and only then swaps a current symlink in one atomic step. Reloading PHP-FPM clears OPcache, and queue:restart tells workers to finish their current job and start on the new code. For Next.js, build into the new release folder too, then reload the Node process gracefully (pm2 reload in cluster mode starts new workers before stopping old ones), or start a new container and switch the proxy after its health check passes. Watch out for version skew: browsers with an old page open may request old JavaScript chunks, so keep previous static assets available for a while.

1#!/usr/bin/env bash
2set -euo pipefail
3APP=/var/www/app
4RELEASE=$APP/releases/$(date +%Y%m%d%H%M%S)
5git clone --depth 1 --branch main [email protected]:your_user/app.git "$RELEASE"
6cd "$RELEASE"
7rm -rf storage && ln -s $APP/shared/storage storage
8ln -s $APP/shared/.env .env
9composer install --no-dev --optimize-autoloader --no-interaction
10npm ci && npm run build
11php artisan migrate --force
12php artisan optimize
13ln -sfn "$RELEASE" $APP/current          # atomic switch
14sudo systemctl reload php8.3-fpm         # match your PHP version
15php artisan queue:restart

07Database migrations and rollbacks

Code can be rolled back in seconds; data cannot. During any deploy, old and new code run at the same time for a moment, so every migration must work with both versions. The expand and contract pattern makes this safe. To rename a column: first add the new column and write to both (expand), deploy, backfill old rows in batches, switch reads to the new column, and only in a later release drop the old one (contract). Avoid long locks on big tables; add indexes concurrently where the database supports it. Roll back by redeploying the previous release folder or image tag, which is why you keep the last few. For the database, prefer rolling forward with a fixing migration over running down migrations in production, and always have a fresh backup before risky changes.

• Additive first: new columns nullable or with defaults.
• Destructive changes (drop, rename) only after no code uses the old shape.
• Keep several previous releases on disk for instant rollback.

08How Git stores your work, and why almost nothing is lost

Git is a content-addressed database. Every file version is stored as a blob, every directory as a tree that lists blobs and other trees, and every commit as an object pointing to one root tree, its parent commits, an author and a message. Each object is named by the hash of its content, so identical files are stored once and any tampering changes the hash. Branches and tags are refs: small files holding one commit hash. HEAD points at the ref you are on. Because commits are never edited, only new ones created, a rebase or reset does not destroy the old commits; they simply lose their label. The reflog records every position HEAD and each branch had, usually for about 90 days, so after a bad rebase or reset you can find the old hash and point a branch back at it. Garbage collection removes unreachable objects only after that grace period.

1git reflog -15                      # where HEAD has been
2git branch rescue HEAD@{3}          # recover the state from 3 moves ago
3git reset --hard ORIG_HEAD          # undo the last rebase or merge
4git fsck --lost-found               # find dangling commits and blobs
5git cat-file -p HEAD                # see a commit object: tree, parent, author

09Securing the pipeline itself

A CI system holds the keys to production, so attackers target it. Four controls matter most. First, least privilege for the job token: declare permissions explicitly at the top of each workflow, read-only by default. Second, avoid long-lived cloud keys entirely: GitHub Actions, GitLab and others can issue a short-lived OIDC token that AWS, Google Cloud or Azure exchange for temporary credentials, restricted to one repository and branch. Third, pin third-party actions to a full commit SHA, not a tag, because tags can be moved by whoever controls that repository. Fourth, be careful with workflows triggered by pull requests from forks: pull_request_target runs with the base repository's secrets, so it must never check out and execute untrusted code. Production deploys should go through a protected environment with required reviewers, so a compromised branch cannot deploy on its own.

1permissions:
2  contents: read
3  id-token: write          # allow OIDC token for cloud login
4jobs:
5  deploy:
6    environment: production  # required reviewers + env-scoped secrets
7    runs-on: ubuntu-latest
8    steps:
9      - uses: actions/checkout@v5
10      - uses: aws-actions/configure-aws-credentials@v6
11        with:
12          role-to-assume: arn:aws:iam::111122223333:role/deploy-web
13          aws-region: eu-central-1

10Build once, promote by digest, and serialise deploys

A mature pipeline builds the artifact exactly once, on the merge to main, tags it with the commit SHA and pushes it to a registry. Staging and production then deploy that same artifact, identified by its immutable digest, so what you tested is byte-for-byte what you ship. Rebuilding for production reintroduces risk: a dependency or base image may have changed in between. Two deploys running at the same time can also leave a server half on each version, so serialise them with a concurrency group, and do not cancel a deploy that is already running, because cancelling halfway is worse than finishing. Record each deployment with its commit, time and author, so the question what is running in production right now has a one-line answer. Rollback is then just redeploying the previous digest.

1concurrency:
2  group: deploy-production
3  cancel-in-progress: false     # queue, never kill a running deploy
4 
5# build stage (once):
6#   docker build -t registry.example.com/web:$GITHUB_SHA .
7#   docker push registry.example.com/web:$GITHUB_SHA
8# deploy stages reuse the same tag/digest, no rebuild

11Schema changes on big tables without locking the site

Expand and contract keeps code and schema compatible, but each step can still lock a table. In PostgreSQL, most ALTER TABLE forms take an ACCESS EXCLUSIVE lock. Even a fast change has to wait for any long-running transaction to finish, and while it waits, every new query on that table queues behind it, so a two-millisecond migration can freeze the site for minutes. Protect yourself with a short lock_timeout and retry. Build indexes with CREATE INDEX CONCURRENTLY, which avoids blocking writes but cannot run inside a transaction, so frameworks that wrap migrations in transactions need it switched off for that migration (in Laravel, set the migration's withinTransaction property to false). Adding a NOT NULL constraint on a huge table is safer as a CHECK constraint added NOT VALID and validated later. On MySQL, prefer ALGORITHM=INSTANT where supported, or tools such as gh-ost for large rebuilds.

1SET lock_timeout = '3s';
2ALTER TABLE orders ADD COLUMN export_status text;   -- metadata-only, fast
3 
4CREATE INDEX CONCURRENTLY idx_orders_export_status
5  ON orders (export_status);
6 
7ALTER TABLE orders ADD CONSTRAINT orders_export_status_nn
8  CHECK (export_status IS NOT NULL) NOT VALID;
9ALTER TABLE orders VALIDATE CONSTRAINT orders_export_status_nn;