Laravel Git Blog - Workflows

A First CI Pipeline for a Laravel Project

Wed, 21 Oct 2026 00:00:00 GMT

CI does not need to be elaborate to be valuable. For a small Laravel team, a first pipeline is four jobs that run on every pull request, and its real product is a green checkmark everyone trusts.

The four jobs

Install: composer install and npm ci. If dependencies cannot install cleanly from the lockfiles, nothing else matters - this is why the lockfiles are committed.
Lint: ./vendor/bin/pint --test fails the build on style drift, so style stops being a code review topic.
Test: php artisan test against a throwaway database (SQLite in memory is enough for a first pipeline).
Build: npm run build proves the frontend compiles - the failure you do not want to meet at deploy time.

Any pipeline runner can express this: GitHub Actions, GitLab CI, or the CI your self-hosted setup provides. The shape is the same everywhere: checkout, cache the composer/npm directories, run the four jobs.

Make the check required

A pipeline nobody is forced to wait for becomes decoration within a month. Wire it into branch protection: pull requests cannot merge until CI is green. That single setting is the difference between "we have CI" and "CI has us" - and it is what lets small PRs move quickly, because reviewers see the robot's verdict before they spend their own attention.

Keep it boring and fast

Two traps make teams abandon CI:

Slow runs. Cache dependencies, and resist running the full browser-test suite on every push - that belongs in a nightly job. A PR pipeline that answers in under five minutes gets respected; one that takes forty gets bypassed.
Flaky tests. A test that fails randomly teaches everyone to click "re-run" without looking, which is worse than no test. Quarantine flakes the week they appear.

What not to automate yet

Deploys. The first pipeline stops at the green checkmark on the PR; deployment stays a deliberate human act until the test suite earns more trust. When that day comes, the pipeline's final job is a tag, and Deploy With Tags, Not Branches takes it from there.

Four jobs, one required check, five minutes. That is the whole first pipeline - everything after is refinement.

A Staging Environment Worth Having

Wed, 21 Oct 2026 00:00:00 GMT

Most staging environments fail quietly: they run different code, on different data, deployed by a different process, so a green staging test proves almost nothing and everyone learns to ignore it. A staging environment earns its cost by being production's rehearsal room, and that property comes from three decisions.

Same deploy path

Deploy to staging exactly the way you deploy to production - same script, same releases and symlink structure, same tag-based flow, differing only in target host. This is the highest-value property: most deploy failures are process failures, and you want to meet them on staging. If production deploys a tag and staging deploys "whatever branch someone pushed," staging is testing a process you do not use.

Same shape of services

Match the services that change behavior: same PHP version, same database engine and version, a real queue worker, a real cache. SQLite on staging against MySQL in production hides the query that only MySQL rejects. The hardware can be smaller - the interfaces cannot.

Sanitized, realistic data

Copy production data down and scrub it: anonymize emails, strip tokens and personal fields, keep the volumes and shapes. User::factory() data has perfect distributions and no history; real data has a user from 2019 with a null middle name that breaks your new export. Laravel's model factories can help fill gaps, but the scrubbed copy is what finds migration surprises.

What staging is for

Decide, write it down, and the environment stays healthy:

Rehearse deploys and migrations before production.
Let someone click through a feature before release.
Reproduce a production bug without touching production.

What it is not: a long-lived fork of production with its own data edits, or a second production for selected users. Both drift, and drifted staging is worse than none - it provides false confidence.

The env file for staging points at its own services but mirrors production's key list, and the quarterly audit keeps it that way. Done right, "it worked on staging" is a sentence worth saying in an incident review.

Branch Naming Conventions That Scale Past Three People

Wed, 21 Oct 2026 00:00:00 GMT

With two developers, branch names do not matter - you both know what everything is. Add a third, then a fifth, and suddenly fix-stuff and stefan-wip-2 are a shared inbox full of unmarked letters. A naming convention is not bureaucracy; it is how a branch list becomes readable at a glance.

The shape that works

BILL-88-retry-failed-invoices
feature/team-invitations
hotfix/checkout-double-charge

Three ingredients, in rough order of value:

A ticket reference when one exists. BILL-88-retry-failed-invoices links the branch to the tracker without opening anything. Tools pick this up automatically - GitHub and GitLab cross-reference, and the PR inherits the link. When there is no ticket, skip it; inventing ceremony for a typo fix is worse than omitting it.
Lowercase words joined by dashes. No underscores, no camelCase, no spaces escaped into %20. Branch names appear in URLs, CI logs and shell commands; the boring format survives all three.
A type prefix for the exceptions. hotfix/ and release/ prefixes earn their keep because they signal urgency and different rules - a hotfix skips the queue (see shipping a hotfix without the drama). Feature branches need no prefix; they are the default case.

The conventions that collapse

Names as ownership. stefan-billing tells you who, not what - and the moment two people touch it, the name is a lie. Ownership lives in the PR assignee, not the branch.

Version branches that never die. v2-redesign living for four months is not a branch, it is a fork with anxiety. If work takes that long, the answer is feature flags and incremental merges, not a longer-lived branch name.

Over-specified formats. type/TEAM-1234/short-description/v1 looks great in a wiki and collapses on contact with reality. Every required element is a place to be wrong.

Pair it with cleanup

Names decay faster than branches. A convention only stays legible if merged branches get deleted - most hosts offer this as a button or an automatic setting - and stale ones get pruned locally (git fetch --prune, or the config version in five git config settings worth changing). A branch list of twelve current names beats a list of two hundred historical ones, whatever convention they follow.

Pick the boring format, write it in CONTRIBUTING.md, and spend the saved energy on the work the branches exist for.

Branch Protection Rules That Stick

Wed, 21 Oct 2026 00:00:00 GMT

Branch protection fails in two ways: too little of it, and so much of it that the team routes around it. For a small team, three rules do most of the work.

1. Require a pull request and one review

Nobody pushes straight to main, including the senior who "just fixes a typo". One reviewer is enough at this size — the point is a second pair of eyes, not a committee.

2. Require checks to pass

The test suite runs on the PR and must be green before merge. This is what keeps "main always runs" true in practice rather than in principle. If the suite is slow, fix the suite — do not downgrade the rule to "tests optional".

3. No force-pushes to main

Shared history is append-only. Rewriting main breaks everyone's clones and makes the audit trail meaningless. Rebasing stays on feature branches, where it belongs.

What to leave out until it hurts

Code-owner reviews, signed-commit requirements, linear-history-only, status checks from five tools — each adds friction that makes sense at a specific size or risk level. Add them when a real incident names the need, not because the settings page offers them.

The test of a ruleset is whether the team still respects it in month six. Small and enforced beats thorough and bypassed.

CODEOWNERS Files: Automatic Reviewers for the Risky Parts of Your Repo

Wed, 21 Oct 2026 00:00:00 GMT

Some pull requests are fine with any reviewer. Some are not: a migration touching a billing table, a change to the deploy script, a tweak to authentication middleware. For those, you want a specific pair of eyes - and you want that to happen by default, not because someone remembered to ask.

A CODEOWNERS file encodes that routing. When a pull request touches a path with an owner, the platform automatically requests the owner's review, and branch protection can require their approval before merge.

The syntax

The file lives at .github/CODEOWNERS (GitHub) or .gitlab/CODEOWNERS (GitLab), and each line is a pattern followed by one or more owners:

# Default owner for everything
* @stefan

# Database changes need the data team
database/migrations/ @stefan @amira

# Deploy and CI config
deploy.sh @ops-team
.github/workflows/ @ops-team

# One specific file
config/services.php @stefan

Patterns follow gitignore-style matching. Later lines override earlier ones for the paths they match, so put the general rules first and the specific ones last.

Where Laravel teams get the most value

You do not need to own every path. Two or three rules cover most of the risk:

database/migrations/ - migrations are hard to roll back and easy to get subtly wrong. Our post on reviewing migrations is the checklist your owner will run through.
Deploy and CI configuration - deploy.sh, workflow files, docker-compose.yml. A broken deploy script costs the whole team's afternoon.
Auth and payment code - the directories where a mistake is a security incident or a billing bug, not just a UI glitch.

Everything else can stay with the team-wide default: anyone reviews, someone approves.

The failure modes

Owner becomes a bottleneck. If every migration needs one person's approval and they are on holiday, work stops. Name at least two owners for critical paths, and keep the required-approvals count at one.

File goes stale. People change roles, teams change shape. A CODEOWNERS file pointing at someone who left is worse than none - it creates the illusion of review. Re-read it when the team changes, the same way you re-read branch protection rules.

Ownership as territory. The file routes review; it does not grant veto over ideas. If "owner approval required" starts meaning "nobody else may touch this," that is a team problem the file merely made visible.

Start small: one file, three rules, two owners per critical path. The first time an automatic review request catches a risky migration before it merges, the file has paid for itself.

Conventional Commits for a Small Team

Wed, 21 Oct 2026 00:00:00 GMT

Six months of commit messages that say "fix", "wip" and "changes" tell the next developer nothing - and on a small team the next developer is usually you. Conventional Commits add one prefix to every message and turn the log into something you can actually read.

The whole format

type(scope): short summary

The types that earn their keep on a Laravel app:

feat - new behaviour (feat(billing): add invoice PDF download)
fix - a bug (fix(queue): stop retrying permanently failed jobs)
refactor - same behaviour, different code
test - tests only
chore - dependencies, config, tooling
docs - the README and friends

The scope is optional but cheap: one word naming the part of the app (billing, queue, auth). The summary stays imperative and under about 70 characters.

What it buys

git log --oneline becomes a changelog draft: everything user-visible is a feat or fix, everything else filters out. That is exactly the input the tags-to-changelog habit needs, and it makes releases a paste-and-edit job instead of an archaeology dig. Review gets faster too - a refactor prefix sets expectations before the diff loads, and nobody hunts for behaviour changes in a commit that announced there are none.

Breaking changes get a ! (feat(api)!: drop v1 endpoints) or a BREAKING CHANGE: footer, so they are impossible to miss at release time.

Adopt it without a fight

The failure mode is process, not spelling: a team that gets a 12-type spec and a CI gate on day one starts writing chore: stuff to make the check pass. Start smaller:

Five or six types, written in the README or pull request template.
Scope optional, body only when the why is not obvious from the diff.
No CI enforcement at first. Squash-merge pull requests and write the conventional message on the squash commit - main stays clean even when the branch's own commits are messy.

If it still feels like overhead after a month, drop it. A convention the team half-follows is worse than none, because it teaches people the log cannot be trusted. The bar is not a perfect history; it is a git log you can skim before a release and believe.

Deploy With Tags, Not Branches

Wed, 21 Oct 2026 00:00:00 GMT

A common small-team setup has a production branch: merge into it, push, and the server pulls it. It works until the day someone commits directly to it, force-pushes it, or merges the wrong thing and the branch history no longer matches what anyone intended. The branch stops being a record and becomes a rumor.

A tag does not have these problems.

What deploying a tag looks like

The release flow is: finish work on main, tag the commit, deploy the tag.

git tag -a v1.14.0 -m "v1.14.0"
git push origin v1.14.0

On the server, instead of git pull, the deploy script fetches and checks out the exact tag:

git fetch --tags
git checkout v1.14.0

That is a detached HEAD on purpose - the server is not a place where commits happen, so there is nothing to lose. The result is that "what is running in production" has one unambiguous answer, and it is the same answer git tag gives everyone on the team.

Why this beats an environment branch

Tags do not drift. A branch can pick up a stray commit; a tag points at one commit forever.
Rollback is a checkout. Deploy the previous tag and you are back, with no revert commit needed - When to Reset, Restore, or Revert stays a developer-machine topic, not a 2 AM production topic.
The release log writes itself. Tag messages and annotated-tag history double as the skeleton of a changelog, which is the whole trick in Keep a Changelog Straight From Git Tags.

The Tagging Releases Properly post covers annotation and naming; this one is about making the tag the unit of deployment.

Keeping staging honest

If you want a staging environment, deploy the same way: tag a release candidate (v1.14.0-rc.1), deploy that tag to staging, and promote by re-tagging or tagging the final release on the same commit. "Staging runs something production has never seen" becomes structurally impossible.

For the full pipeline around this - build steps, env handling, the push-to-server mechanics - Deploy Laravel With Git Push walks through it. The short version of both posts: branches are for work in progress, tags are for facts. Deploy facts.

Does Your Team Need a Merge Queue? Probably Not Yet

Wed, 21 Oct 2026 00:00:00 GMT

A merge queue is CI's answer to a sneaky failure: two pull requests, each green against main, that break when combined. One renames a function; the other adds a new call to the old name. Both pass, both merge, main is red. The queue fixes this by testing each PR against main plus everything already queued, so "green" means "green against what main will actually be."

GitHub, GitLab and Bors all offer one. The question is not whether they work - they do - but whether your team has the problem they solve.

The threshold

The broken-main-from-colliding-PRs problem needs two ingredients: enough parallel merges that collisions are likely, and a test suite slow enough that "just rebase and rerun CI" is painful. A team merging three pull requests a day with a five-minute suite almost never sees it. A team merging thirty a day with a forty-minute suite sees it weekly.

Some honest signals you have crossed the line:

Main breaks from semantic conflicts more than once a month, and each break costs real debugging time.
Reviewers ask authors to "rebase and make sure it is still green" so often that the rebase-rerun loop is the bottleneck.
Releases get delayed because main went red at the wrong moment.

What to do before you get there

Most small teams get the same protection cheaper:

Keep CI fast. A five-minute suite makes "rebase and rerun" a shrug, not an afternoon. This is the same investment as always - shallow clones and dependency caching - and it pays whether or not you ever need a queue.
Require branches to be up to date before merging on the riskiest repo. GitHub's branch protection has this checkbox; it forces the rebase-rerun loop explicitly, which is exactly a manual merge queue. Fine at low volume, painful at high volume - which is your signal.
Merge promptly after approval. Most collisions happen because approved PRs sit for days while main moves on. A queue will not fix a review-and-forget habit; small pull requests will.

When the manual loop becomes the thing slowing everyone down, the queue stops being infrastructure cosplay and starts paying rent. Until then, the honest answer is: not yet - and here is how you will know.

Use Draft Pull Requests to Get Feedback Early

Wed, 21 Oct 2026 00:00:00 GMT

The traditional pull request arrives finished: code done, tests written, author braced for judgment. By that point the expensive decisions are locked in, and "have you considered a different approach?" means redoing two days of work. A draft PR flips the order - feedback lands while changing course is still cheap.

What a draft is for

Open the PR as a draft the moment the shape of the change exists: the migration, a sketched controller, maybe a failing test that names the behavior. The draft status says plainly: do not review the details yet, do look at the direction.

That early look catches the reviews that matter most:

"This duplicates what the billing package already does" - before you polish your version.
"The column should live on the invoices table, not the users table" - before the migration ships.
"We tried this approach in March, here is why it hurt" - before you rediscover March.

The working agreement

Drafts only work if the team reads them in the right spirit. Two conventions keep it healthy:

The author says what they want. "Does this structure make sense?" gets a useful answer; silence about intent gets either no review or a full one you did not want yet. The PR description matters more, not less, in a draft.
Nobody treats a draft as a promise. Scope can shrink, approach can change, the branch can be rebased - drafts are force-push-with-lease territory by default.

Marking the PR ready for review is then a real signal: the direction is settled, now judge the details.

The quiet side benefit

Drafts double as a status board. A team that opens drafts early can see what is in flight without asking - which prevents the awkward moment where two people discover at merge time that they both spent the week on the same invoice controller. It also feeds the habit that keeps everything else moving: work arrives in small, reviewable pieces, because a draft that has been open for three weeks is visibly not that.

Open it early, say what you want, mark it ready when it is. The PR stops being a verdict and becomes a conversation - which was the point of having a team.

Feature Flags: How to Merge Daily Without Shipping Half-Built Work

Wed, 21 Oct 2026 00:00:00 GMT

The argument for a long-lived feature branch goes: the work takes three weeks, it cannot ship half-done, so it lives on a branch until it is ready. The cost shows up at the end - a three-week merge, conflicts with everything that moved underneath, and a review nobody can hold in their head.

Feature flags attack the premise instead of the branch. If unfinished code can sit in production safely, invisible behind a flag, there is no reason to keep it out of main.

What a feature flag is

A flag is a runtime check around new behaviour:

if (feature('new-billing-dashboard')) {
    return view('billing.dashboard-new');
}
return view('billing.dashboard');

Laravel teams have good options for the feature() part: Laravel Pennant (first-party, ships with recent Laravel versions), a config value, or an external service. The mechanism matters less than the habit: new behaviour ships dark, off by default, and turns on when it is ready - per user, per team, or for everyone.

Why it pairs with trunk-based development

Trunk-based development asks for small, frequent merges into main. The objection is always "but my feature is not done." Flags answer it: merge the first slice behind a flag on Monday, the second on Wednesday, the third next week. Each merge is small, reviewed quickly, and deployed continuously - while users see nothing until you flip the flag.

The bonus nobody expects: rolling out to 5% of users, then 50%, then everyone is free. And if something breaks, "roll back" is turning the flag off - no revert deploy, no drama, exactly the cheap-exit thinking in rollback or roll forward.

The disciplines that keep flags healthy

Name flags for the feature, not the date. new-billing-dashboard is clear in six months; experiment-2026-10 is not.

Flag the smallest unit of behaviour. One flag around one feature. A flag that controls three unrelated things cannot be turned off cleanly when one of them misbehaves.

Delete flags when the rollout finishes. A flag that stays at 100% forever is an if statement with extra steps. Make "remove the flag" the last task on the feature ticket, and grep for stale flags every quarter. This is the unglamorous part, and the part that decides whether flags stay a tool or become sediment.

Start with one flag on your next multi-day feature. The first time you merge on day one instead of week three - and turn the thing off from your phone when it misbehaves - the branch-everything habit loses its grip.

Git Bisect: Find the Commit That Broke It

Wed, 21 Oct 2026 00:00:00 GMT

Something that worked last release is broken now, and forty commits sit between then and now. Reading every diff is the slow way. git bisect does a binary search over the range, so six checks find the culprit instead of forty.

Mark the ends

git bisect start
git bisect bad            # the commit you are on is broken
git bisect good v1.4.0    # the last tag you know was fine

Git checks out a commit in the middle. Run whatever reproduces the bug — the feature test, the artisan command, the page that 500s — then tell Git the answer:

git bisect good   # or: git bisect bad

Repeat. Each answer halves the range, and after a few rounds Git names the first bad commit with its full diff and message.

Let the test suite drive

If a single command answers "is this commit broken", hand the whole search to it:

git bisect run php artisan test --filter=CheckoutTest

Bisect now walks the range alone, marks each commit from the exit code, and stops on the first failure. This is the version worth using: it is fast, and it removes the temptation to eyeball a step and guess.

Two practical bumps

A commit that cannot run at all — a dependency changed and the test cannot boot — stalls the search. git bisect skip tells Git to step over it, and git bisect run can skip automatically when the command exits with 125.
Vendored directories move between commits. Between steps you may need composer install; inside bisect run, a tiny shell script that runs it before the test keeps every commit bootable.

When it names a commit

git bisect reset

That returns you to where you started. The bisect log disappears, so note the hash first. The usual next step is not the fix — it is a failing regression test on current main that proves the bug, so the fix that follows can never quietly regress.

Bisect rewards the boring habits: small commits that each boot, and tags you can trust as "known good". Those habits are cheap right up until the day they are the fastest way back to a working app.

Managing .env Files Across Environments

Wed, 21 Oct 2026 00:00:00 GMT

Every Laravel app has the same three-way split: your laptop, a staging server, production. Each needs its own .env, and the .env itself must never be committed - What Not to Commit covers why. What is worth deciding deliberately is how the values get to each environment and how the team learns about new keys.

.env.example is the contract

Commit .env.example with every key and a safe placeholder value, and treat it as part of every pull request that adds configuration:

MAIL_MAILER=
QUEUE_CONNECTION=
INVOICE_SIGNING_KEY=

A new hire runs cp .env.example .env, fills in the blanks, and the app boots. A reviewer sees the new key in the PR diff without seeing its value. When someone adds a key to their local .env without updating the example, the next person's setup breaks quietly - so make "PR adds a key to .env.example" as automatic as "PR includes a migration".

Getting values to servers

Servers have no checkout step where you can edit a file by hand, so pick a delivery mechanism:

The deploy tool's secrets store (most managed deploy platforms have one).
A file written by your deploy script from your password manager or vault - never from the repo.
On a self-hosted box you administer: a plain .env in the shared directory of your releases structure, permissions 600, owned by the deploy user.

All three share one property: the value's home is outside Git, and changing it does not require a commit.

After changing values

Laravel caches config aggressively in production, so a changed .env does nothing until you rebuild the cache:

php artisan config:cache

Fold that into the deploy script and "I changed it but nothing happened" stops being a genre of bug report. Also restart the queue workers - they hold the old config in memory, same lesson as the deploy post's queue:restart.

The audit habit

Once a quarter, diff each environment's keys against .env.example: keys present on servers but missing from the example are undocumented config, and keys in the example that no environment sets are dead weight. Two minutes with comm on sorted key lists keeps the contract honest.

Secrets stay out of history - and if one ever lands there, A Secret Got Committed. Now What? is the cleanup drill.

Merging vs Rebasing on a Small Team

Wed, 21 Oct 2026 00:00:00 GMT

Few git arguments cost more than they settle. The working rule for a small team fits in one sentence: rebase your own branch, merge into main.

Rebase is for your branch

While your branch is still yours, keep it current and readable:

git fetch origin
git rebase origin/main

Your commits replay on top of main, conflicts show up in small pieces while you still remember the change, and the branch reads like a story a reviewer can follow.

Merge is for main

When the branch is done, merge it. The merge commit marks where the work landed and keeps the group's shared history untouched:

git checkout main
git merge --no-ff pr-42-branch

--no-ff keeps the feature visible as one unit, which makes the changelog draft and any later revert much easier.

What not to do

Never rebase a branch someone else has pulled. Rewriting shared history is how teammates lose work and trust the repo a little less. If it is pushed and shared, it merges.

That is the whole policy. Write it in the README and spend the argument on the code instead.

Monorepo or Many Repos for a Small Laravel Team

Wed, 21 Oct 2026 00:00:00 GMT

Laravel projects grow extra code over time: a shared package, an internal admin tool, maybe a second app that reuses the first one's domain logic. At some point you have to decide whether everything lives in one repository or gets split into several.

Start with one repo

For a small team, one repository is the right default for a simple reason: every change is atomic. When the app and its shared package live together, a rename lands in a single commit, CI runs once, and there is no version matrix to keep in your head. Composer makes this comfortable with path repositories:

"repositories": [
  { "type": "path", "url": "packages/billing" }
],
"require": {
  "acme/billing": "*"
}

The package sits in packages/billing inside the same repo, and Composer symlinks it in. You get the directory structure of a split without any of the coordination cost.

When splitting starts to make sense

Split a repo only when one of these becomes true:

A package is genuinely reused across projects with different release cadences, and tagging it independently matters.
Different people should have different access rights - a contractor on the marketing site should not see billing code.
CI time is dominated by unrelated code, and path-scoped pipelines cannot fix it.

"One day this might be an open-source package" is not on the list. That day can be handled when it arrives.

Splitting later, keeping history

When the day comes, you do not have to lose history. git subtree split extracts a directory into its own branch with every commit that touched it, ready to push into a fresh repository:

git subtree split --prefix=packages/billing -b billing-history

That is a much better story than the usual alternative of planning repository topology up front for a future that may never happen. It is also worth contrasting with submodules, which solve a different problem - vendoring an outside dependency with its own history - and bring real day-to-day friction.

The short version: one repo until something concrete hurts, path repositories for internal packages, subtree split when a package earns its independence. Repository topology is a scaling decision, and small teams scale by not making it early.

Onboarding a New Developer to Your Git Workflow

Wed, 21 Oct 2026 00:00:00 GMT

Every team has a Git workflow, but most teams keep it in their heads. A new developer then learns it by breaking it: committing to the wrong branch, force-pushing the wrong thing, opening a 2,000-line PR on day three. A one-page written workflow and a little automation fix most of this before it happens.

Write down the five decisions

However your team works, these five choices define it. Put them in the README or CONTRIBUTING.md:

Where work happens: feature branches off main, or straight to main for tiny teams.
How branches are named: feature/short-name, fix/thing, whatever - consistency matters more than the scheme.
What a pull request needs: description, linked ticket, one approval, green CI.
How merges land: merge commit, squash, or rebase - Merging vs Rebasing for Small Teams if this is still unsettled.
How releases happen: tags, changelogs, deploy steps. Tagging Releases Properly covers the shape.

A new hire who can read those five lines commits correctly on day one.

Automate what is enforceable

Rules that live only in the document decay. The ones that survive are enforced by the repo itself:

Branch protection on main, so "don't push to main" is a fact, not a preference.
Git hooks for the local checks - Pint, tests, no debugging leftovers.
Conventional commits if the team wants parseable history, with a commit-msg hook to back it.

Automation also shortens the document: you stop writing rules down once the tooling states them for you.

Pair on the first pull request

The highest-leverage onboarding hour is walking a new developer through their first PR the team's way: small branch, tidy commits, a description a stranger could review from, responding to comments without defensiveness. Point them at the team's own posts on small pull requests and PR descriptions if you have them - or write yours down once and link it forever.

The measure of a good onboarding is how boring the second week is: the new hire ships a small PR, gets one round of comments, merges, and nobody had to correct a Git habit. That outcome is designed, not lucky.

Pull Request Templates That People Actually Fill In

Wed, 21 Oct 2026 00:00:00 GMT

A pull request with an empty description is a small act of unkindness to its reviewer. They have to reconstruct the intent from the diff, guess at the testing, and ask questions the author could have answered in thirty seconds. Teams fix this with a template - then often ruin it by making the template a questionnaire nobody reads.

What a template is for

Drop a file at .github/pull_request_template.md (or .gitlab/merge_request_templates/Default.md) and every new pull request starts with its contents pre-filled. The author's job shifts from "write something from nothing" to "fill in the blanks" - which is a much lower bar, and that is the whole point.

The sections that earn their place

Three prompts cover almost everything a reviewer needs:

## What
One or two sentences: what does this change do?

## Why
What problem does it solve? Link the ticket if there is one.

## How tested
What did you run, click, or deploy to staging to convince yourself?

"What" and "why" are the difference between a review and an interrogation. "How tested" is the one authors skip when there is no prompt, and the one that catches "I did not actually run it" before the reviewer does.

For risky changes, one optional line helps: **Risk:** what breaks if this is wrong? Leave it in the template as a comment or optional heading, and the answer doubles as your rollback plan - which pairs well with the habits in rollback or roll forward.

What to leave out

Every field you add is a tax on every pull request. Skip:

Long checklists of things CI already checks. "Tests pass" is a status badge, not a checkbox.
Legalistic boilerplate. Nobody has ever been protected by "I confirm I have read the contributing guide."
Sections that only apply to one pull request in fifty. Database migration notes, screenshots, API changes - authors will add these when relevant. A heading they must delete is friction, not help.

If a section is empty on most merged pull requests, cut it.

Keep it alive

A template is a living document with exactly one success metric: do merged pull requests have useful descriptions? Skim the last ten. If "How tested" is always "yes", sharpen the prompt ("what command did you run?"). If a section is always deleted, remove it.

The template is also a forcing function for smaller work: a pull request too big to describe in two sentences is a pull request that should be split, which is exactly the argument in small pull requests get reviewed faster. And when the description is written, the advice in writing a good pull request description makes it land.

Start with three headings and resist every addition. The best template is the one nobody notices.

Rollback or Roll Forward? Decide Before You Need To

Wed, 21 Oct 2026 00:00:00 GMT

Something is wrong in production. The temptation is to start fixing immediately - but the first decision is which direction to move: back to the last good release, or forward to a fix. Teams that decide the criteria in advance make this call in seconds; teams that improvise it make it under pressure, badly.

Roll back when you can

Going back is the better default whenever it is actually available:

The bug is in the new code, not in data the new code wrote.
No migration in this release changed the schema in a way old code cannot live with.
Your deploys are structured for it - a symlink swap back, or deploying the previous tag.

A rollback is one known-good state replacing one known-bad state. There is nothing to debug; you are simply not on fire anymore.

Roll forward when you must

Sometimes back is closed:

A destructive migration already ran - dropped or renamed columns the old code expects.
Users have created data under the new behavior, and reverting would strand or corrupt it.
The "old" state has its own known bug that this release was fixing.

Then the fix is a new commit on main, reviewed as fast as a review can responsibly go, deployed as a new release. Note what rolling forward is not: committing directly to the server's working tree. Even mid-incident, the fix goes through Git - a branch, a very short PR, a deploy - because the history of what happened during the incident is exactly what you will want afterwards. When to Reset, Restore, or Revert covers the mechanics; the revert of the bad commit belongs in history either way.

The deciding question

Ask one thing: can the old code run against the current database? If yes, roll back - it is faster and safer than any fix you will write under stress. If no, you are rolling forward, and the time to accept that is immediately, not after forty minutes of trying to make rollback possible.

The two habits that keep the rollback door open are boring ones: backward-compatible migrations, and releases structured so going back is one command. Both are decided on quiet days, which is the only time incident decisions ever get made well.

Shipping a Hotfix Without the Drama

Wed, 21 Oct 2026 00:00:00 GMT

Production is broken and main has moved on - it contains three half-finished features that cannot ship today. The hotfix question is how to patch what is live without dragging main along. The answer is short: branch from the tag that is running, fix there, tag, deploy, merge back.

The walkthrough

git switch -c hotfix/invoice-total-rounding v1.14.0
# fix the one thing, with a test
git tag -a v1.14.1 -m "v1.14.1"
git push origin hotfix/invoice-total-rounding v1.14.1

Deploy v1.14.1 exactly the way you deploy everything else - Deploy With Tags, Not Branches applies even more under pressure, because "what is running" must have one unambiguous answer during an incident.

Then bring the fix home so the next regular release does not reintroduce the bug:

git switch main
git merge hotfix/invoice-total-rounding

Discipline under pressure

The rules that keep a hotfix small:

One fix. A hotfix branch is not a vehicle for the cleanup you noticed on the way in. Everything else goes into a normal PR tomorrow.
The test comes too. If the bug was reachable once, it is reachable again; the test is what makes "fixed" verifiable rather than hoped. This is the moment the first CI pipeline earns its keep - the hotfix PR gets the same green check as everything else.
No shortcuts around review. One approval, even a two-minute one, catches the mistake made at speed. Branch protection should have no "except hotfixes" hole; it should have a fast path through the normal gate.

If the fix is bigger than a hotfix

When the honest assessment is "this needs a day of work," stop calling it a hotfix and decide rollback or roll-forward instead. A rollback buys the day cleanly. The worst outcome is the middle path: an ever-growing hotfix branch that is secretly a release, deployed with none of the care a release gets.

Branch from the tag, fix one thing, tag, merge back. Written down and rehearsed once, the next production bug is a procedure, not an event.

Squash Merge or Merge Commit: Choosing at the PR Button

Wed, 21 Oct 2026 00:00:00 GMT

The pull request is approved and the button offers a choice: merge commit, squash, or rebase. The code landing on main is identical either way; what changes is the story main tells afterwards.

Merge commit: keep the branch as it was

A merge commit preserves every commit on the branch plus a marker joining it to main. Choose it when the branch's commits are already clean - tidied with an interactive rebase, each one a real step. Main keeps the full context, and git log --graph shows the branch as a readable bubble.

The cost: if the branch was full of "wip" and "fix", all of that lands on main forever.

Squash: the branch becomes one commit

Squashing collapses the whole PR into a single commit on main. Choose it for the common case: a feature branch with exploratory, fix-as-you-go commits whose value was the journey, not the record. Main gains one commit per piece of work, which is exactly the granularity a changelog and a git log --oneline scan want.

Two things make squashing work well. Write the squash commit message properly - it is the only message main will keep, so give it the conventional prefix and a real summary. And delete the branch after merging: pushing more commits to a branch that was already squash-merged produces a follow-up PR full of commits main already has, because the squashed commit shares no history with them.

Rebase merge: linear, commit by commit

Rebasing at merge replays the branch's commits onto main one by one, no merge bubble. Choose it for small PRs that are already clean and where the team wants a strictly linear main. It asks the most of the branch - every commit lands verbatim, "fix typo" included - so it only suits branches that were tidied first.

A rule a small team can keep

Branch is messy (the usual case): squash, write a real message, delete the branch.
Branch is clean and the steps matter: merge commit.
Branch is clean and tiny: rebase is fine, but squashing it is fine too.

Agree on it once, write it in the README, and the choice stops costing a thought per PR.

The Reflog: Undoing Almost Anything in Git

Wed, 21 Oct 2026 00:00:00 GMT

Git rarely loses commits; it loses your pointer to them. The reflog is the record of everywhere HEAD has been, and it turns most "I destroyed everything" moments into a two-minute fix.

Find where you were

git reflog

Every line is a position HEAD held, newest first: checkouts, commits, resets, rebases. Find the entry just before the mistake — its message usually names the operation that went wrong.

Go back there

git reset --hard HEAD@{2}

Or, safer, put a branch on the good position first and look at it before resetting anything:

git branch rescue HEAD@{2}

The classic recoveries

git reset --hard one commit too far: the "lost" commit is in the reflog, reset back to it.
Deleted branch you still needed: git reflog, find the last commit the branch pointed at, git branch the-name <hash>.
Rebase gone wrong: the reflog holds the branch's pre-rebase position as HEAD@{n} from before the rebase started.

The limits

The reflog is local and expires (90 days by default for reachable entries). It saves you from your own commands, not from a disk dying — that is what the remote is for. And uncommitted work that was never staged is genuinely gone; the reflog only tracks commits.

When in doubt, git branch rescue first. A branch you delete after inspecting costs nothing.

Trunk-Based Development on a Small Laravel Team

Wed, 21 Oct 2026 00:00:00 GMT

Long-lived feature branches feel safe and bill you later: the two-week branch that takes a day to merge, and the merge nobody wants to re-run. Trunk-based development is the alternative that works well for small teams.

The rules, sized for a small team

Everything targets main. Branches live hours to a couple of days, never weeks.
Main always runs: tests pass, migrations apply, the app boots.
Review is quick and small, because the changes are small.

Half-done work still merges

The objection is always "the feature is not finished". Merge it anyway, behind a flag. In Laravel that is a config entry or a Feature::active() check, not a branch:

if (config('features.new_billing')) {
    // new flow
}

Delete the flag when the feature ships. A flag you forget is cheaper than a branch you rebase for a month.

What it buys

Conflicts stay small because diffs stay small. Main is deployable any day, so the git-push deploy from a tag or from main stops being an event. And code review gets read, because there is finally little enough of it.

Start with the rule that matters most: nothing lives on a branch longer than two days.

What Not to Commit in a Laravel Project

Wed, 21 Oct 2026 00:00:00 GMT

A Laravel repo should hold the recipe, not the kitchen. The generated and environment-specific parts belong elsewhere.

The .gitignore that covers it

/vendor
/node_modules
.env
.env.backup
.phpunit.result.cache
/public/build
/public/hot
/storage/*.key
/storage/logs/*.log
Homestead.json
Homestead.yaml

Laravel's default .gitignore ships most of this. The ones people add by hand are the environment files and the editor/OS noise (.idea, .DS_Store — those belong in your global gitignore, not the project's).

Why each one stays out

vendor/ and node_modules/ are rebuilt by composer install and npm ci from the lock files — which you do commit.
.env is per-machine by definition and carries secrets. Commit .env.example with the keys and empty values instead.
public/build is Vite output; it gets rebuilt on every deploy.
storage/*.key and logs are runtime state, different on every server.

Already committed something?

git rm --cached -r vendor stops tracking it without deleting your local copy, then commit the removal. If the file carried a secret, that is not enough — the history still has it, and the rotate-first routine applies.

What to Do in a Detached HEAD

Wed, 21 Oct 2026 00:00:00 GMT

"You are in 'detached HEAD' state" reads like a warning that something broke. Nothing broke. Git is saying your HEAD - the pointer that normally sits on a branch - is pointing directly at a commit. Everything works; the only real question is what happens to commits you make here.

How you got here

The usual doors in:

git checkout 3357a04      # inspect an old commit
git checkout v1.4.0       # look at exactly what a tag shipped

Bisect and rebase also park you here on purpose. Checking out a tag to reproduce a bug against the exact deployed code is a completely ordinary reason to be detached.

Looking is free, committing is fine, leaving is the catch

Read files, run the test suite, boot the app - the working tree is real. You can even commit. The catch: no branch points at those new commits, so when you switch away they become unreferenced, and the only thing that will ever find them again is the reflog.

So the rule is simple. The moment you make a commit you want to keep, give it a branch:

git switch -c fix/reproduce-invoice-bug

That is the whole fix. HEAD now points at a normal branch holding your work, and the detached state is over.

If you already switched away

The commits are not gone; they are unreferenced. Find the hash you were on:

git reflog

The recent checkouts are right at the top. Put a branch on the hash:

git branch rescue 3357a04

The reflog keeps these entries for 90 days by default, so "I detached, committed, and switched away an hour ago" is a two-command recovery, not a lost afternoon.

The habit

Treat detached HEAD as a reading room, not a workspace. Look all you want; the instant you write something worth keeping, git switch -c before you do anything else - especially before switching branches, which is the moment the work becomes findable only through the reflog.

If you find yourself detaching often just to run someone else's PR without disturbing your working tree, that is the job worktrees do without the detachment at all.

When to Reset, Restore or Revert

Wed, 21 Oct 2026 00:00:00 GMT

Git has three undo commands and they are not interchangeable. restore touches uncommitted work, reset moves your own branch, and revert undoes a commit that other people may already have. Picking by what you are undoing - and who has seen it - keeps undo boring.

Restore: uncommitted work

You edited a file and the change is wrong. It is not staged, not committed:

git restore app/Models/Invoice.php

Staged it by accident but still want to edit? Unstage without losing the edit:

git restore --staged app/Models/Invoice.php

Restore only reaches work that exists in some committed form. An edit to a file that was never committed anywhere is gone for good once restored away.

Reset: commits nobody else has

You committed on your branch, have not pushed, and want those commits back as working changes:

git reset --soft HEAD~1    # undo the commit, keep everything staged
git reset HEAD~1           # undo the commit, keep the changes unstaged
git reset --hard HEAD~1    # undo the commit and throw the changes away

Reset rewrites the branch, so it belongs to history only you have seen. If a commit is already on the shared remote, reset is how you end up force-pushing over a teammate's work.

Revert: commits everyone has

A commit is on main, the deploy from it broke invoices, and the team has pulled it:

git revert 3e39e4f

Revert adds a new commit that applies the inverse diff. History keeps growing forward, nobody re-pulls a rewritten branch, and git revert of the revert brings the change back when the fix is ready. On a Laravel app this pairs cleanly with rollback: revert the commit, run php artisan migrate:rollback if it carried a migration, deploy again.

The rule of thumb

Not committed: restore.
Committed, not pushed: reset.
Pushed: revert.

When the mistake is bigger than one commit - a wrong rebase, a reset too far - the reflog remembers where the branch was before any of it. And when you are about to undo something you are not sure about, git branch rescue first: a branch you delete after inspecting costs nothing.

Why Git Blame Is Not About Blame

Wed, 21 Oct 2026 00:00:00 GMT

The name is the worst thing about git blame. The command does not exist to find someone to fault; it exists to answer the question every developer asks twenty times a week: why is this line here?

From line to decision

git blame app/Models/Invoice.php

Every line comes back annotated with the commit that last touched it, the author and the date. The commit hash is the valuable part - follow it:

git show 8c6e7ec

Now you have the full diff, the commit message, and usually the pull request it came from. That chain - line, commit, message, PR - is the difference between staring at a strange condition and understanding the edge case it guards.

Two options earn their keep:

git blame -L 40,60 app/Models/Invoice.php   # just these lines
git blame -w config/queue.php               # ignore whitespace-only changes

-w matters more than it looks: without it, the last person to reindent a block "owns" every line in it.

Hide the reformat commit

Every repo has one: the day the whole codebase was reformatted, and blame started pointing every line at it. Git has a built-in answer:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Put the reformat commit's hash in .git-blame-ignore-revs, commit the file, and blame skips those revisions on everyone's machine. GitHub honours the same file in its blame view, so the fix works locally and in the browser.

When blame is the wrong tool

Blame shows the last commit to touch a line. To find when something appeared or disappeared entirely - a setting, a constant, a call - the pickaxe is better:

git log -S 'QUEUE_CONNECTION' --oneline -- config/queue.php .env.example

The culture part

Used as a name-and-shame tool, blame makes people defensive and teaches them to avoid touching old code. Used as a documentation tool, it does the opposite: the author of a line is the person most likely to remember the constraints behind it, and "what were we solving here?" gets a useful answer where "who broke this?" gets silence.

The habit to build is simple. When a line surprises you, blame it, read the commit, and ask about the decision - not the person.

Why You Should Force Push With --force-with-lease

Wed, 21 Oct 2026 00:00:00 GMT

If you rebase, squash or amend, you will eventually need to force-push. The question is never whether force-pushing is evil - it is whether the push can silently delete someone else's work. Plain --force can. --force-with-lease cannot.

The legitimate case

Your PR branch, reviewed once, now rebased onto current main with the fixups squashed in. The remote still holds the pre-rebase version, and the only way to update it is a force-push. That is fine: the branch is yours, and nobody should be building on it.

What --force actually says

git push --force

"Make the remote branch point here, whatever it points at now." If a teammate pushed a commit to your branch since your last fetch - a reviewer fixing a typo through the web UI is the classic way - that commit is gone from the branch, and nobody was asked.

What --force-with-lease says

git push --force-with-lease

"Make the remote branch point here, but only if it still points where my last fetch left it." The lease is your local record of the remote ref. If the remote moved - anyone pushed anything - the push is refused and nothing is overwritten. You fetch, look at what arrived, rebase onto it, and push again.

For another layer, --force-if-includes additionally checks that the remote's current commits are already part of what you are pushing, which catches some stale-reflog corner cases the lease alone misses.

The two rules that make it boring

Never force-push a branch other people build on. Main, release branches, long-lived feature branches: these get merges and reverts, not rewrites. Branch protection should simply forbid it there.
On your own short-lived branches, always --force-with-lease, never bare --force. Put it in muscle memory or in an alias, because the one time you reach for plain --force is the one time the remote had a surprise waiting.

If the worst already happened and a force-push ate a commit, it is recoverable: the commit still exists on the machine that made it, and that machine's reflog knows the hash. A git push <hash>:refs/heads/branch-name from there puts it back.

Writing a CONTRIBUTING.md People Actually Read

Wed, 21 Oct 2026 00:00:00 GMT

Most CONTRIBUTING.md files fail the same way: they are written for the maintainer's peace of mind, not the reader's goal. A new contributor - or a teammate joining the project, which is the same reader - wants three answers: how do I run this, how do I change it, and how do I get the change accepted. Write those, in that order, and stop.

1. Setup that actually works

The first section is the one that gets read: clone, install, run. For a Laravel app that is the composer install, .env setup (which our env files guide covers properly), migrations, and the one command that proves it works - php artisan serve, npm run dev, the test suite.

The test is brutal and simple: hand the repo to someone who has never seen it and watch. Every place they stop is a line your guide is missing. Do this once a year, because setup rots.

2. The workflow, concretely

Branch naming if you have a convention, what a pull request should look like (link your PR template if you have one), who reviews, and how long a review usually takes. That last one matters more than anything else in the file: "expect a first review within two working days" turns waiting from neglect into process.

Keep it to what a contributor does, not how the team philosophizes. Three paragraphs is plenty.

3. The bar for merging

What CI must pass, whether commits get squashed (see squash merge or merge commit), any style tooling that will reject the PR - Pint, ESLint, whatever runs. Contributors forgive strict rules; they do not forgive discovering them in a red CI run after pushing.

What to leave out

Code of conduct boilerplate in the same file. Worth having, worth its own file - GitHub surfaces CODE_OF_CONDUCT.md separately.
Architecture essays. Link the README or docs instead; a guide that takes twenty minutes to read gets zero minutes.
Rules nobody enforces. Each one teaches the reader that the file is decorative, and then they skip the real rules too.

A contributing guide is a promise: follow this and your work lands. Every line either keeps that promise shorter or makes it longer. Keep the short ones.

Writing a Postmortem That Actually Changes Something

Wed, 21 Oct 2026 00:00:00 GMT

The deploy broke billing for forty minutes. Everyone is relieved it is over, everyone is tired, and now someone has to write the postmortem. The temptation is a document that says "a mistake happened, we fixed it, we will be more careful." That document is worse than none: it performs learning without doing any.

A postmortem that changes things has three sections, and each has a rule.

Timeline: facts, in order, with timestamps

When did monitoring fire, who saw it, what did they try, when did recovery start. Written from logs and chat history, not memory - memory edits itself within hours. The timeline is where you discover the real story: the alert that fired twenty minutes before anyone looked, the rollback that took fifteen minutes because nobody remembered the command (which is why rollback or roll forward exists as a pre-made decision, not an improvised one).

Rule: no judgments in the timeline. "Deployed v2.3.1 at 14:02" is a fact. "Deployed carelessly" is a verdict, and verdicts here make people defensive before you reach the part that matters.

Contributing factors: plural, and never a person's name

"Stefan merged the bad migration" is not a cause; it is a scapegoat. The contributing factors are the things that made the mistake easy and its blast radius large: migrations deploy without a dry run, the billing smoke test only runs hourly, one person holds the rollback knowledge. Any of these could bite a different person next week, which is exactly why they are the fixable layer.

Rule: if a factor cannot be assigned to a system, a process or a missing safeguard, keep digging.

Actions: owned, dated, small

Every action has one name and one date. "Improve testing" is a wish; "Amira adds a billing smoke test to the deploy pipeline by Nov 7" is an action. Three real actions beat ten aspirational ones - and they go in the tracker, not just the document, because a postmortem action without a ticket is a hope.

Rule: review the actions at the next incident review or team meeting. An action that slips twice gets escalated or honestly dropped; silently forgotten is the one outcome that teaches the team postmortems are theater.

Write it within two days, share it where everyone can read it, and thank the people named in the timeline - they are the ones who told you the truth.

Zero-Downtime Deploys for Laravel, Explained Simply

Wed, 21 Oct 2026 00:00:00 GMT

The naive Laravel deploy is git pull on the live directory, and it has a window where the code is half-old, half-new - composer autoloads one version, the templates reference another, and a visitor in that second gets a broken page. Zero-downtime deploys remove the window with one idea: never change the directory the web server is looking at.

Releases and one symlink

The structure, used by every deploy tool worth using:

/var/www/app/
  releases/
    20261020-141122/
    20261021-093015/
  current -> releases/20261021-093015
  shared/
    .env
    storage/

Each deploy is a full checkout into a new timestamped directory. Composer install, artisan config:cache, asset builds - all happen there, while current still points at the previous release and the site keeps serving it. The switch is a single atomic operation: repoint the current symlink. If anything is wrong, point it back - rollback takes one second because the old release directory is still intact.

Two things must live outside releases: .env and storage/. Symlink them in from shared/ so every release uses the same environment and the same uploaded files.

Migrations are the hard part

Code swaps are easy; databases cannot be symlinked back. The rule that keeps deploys reversible: every migration must work with both the old and the new code. Adding a column is fine. Renaming one is not - do it as three deploys (add new, backfill and dual-write, drop old). Run php artisan migrate --force before the symlink swap, so the schema is ready for the release that is about to go live.

The queue and scheduler

Laravel queues hold serialized jobs, so after the swap, restart the workers (artisan queue:restart) or they keep running the old code from memory. The scheduler needs no restart - cron resolves through current on each run.

That is the whole shape: build beside, switch atomically, migrate compatibly, restart workers. Whether you script it yourself or adopt a tool, Deploy Laravel With Git Push covers the pipeline around it, and Deploy With Tags, Not Branches decides what each release directory should contain. A deploy your users never notice is not luxury - it is just structure.

A Secret Got Committed. Now What?

Sun, 18 Oct 2026 00:00:00 GMT

It happens: .env, an API key, a database password ends up in a commit. The fix is the same every time, and the order matters.

1. Rotate the secret first

Deleting the file from git does nothing while the key still works. Assume anything committed is public, even in a private repo: clones, forks and CI caches all copy it. Revoke or rotate the credential at the provider before touching the repository.

2. Scrub the history

Once the old key is dead, remove it from history so the repo stops carrying it. git filter-repo is the tool that works:

pip install git-filter-repo
git filter-repo --path .env --invert-paths

This rewrites every commit, so force-push and have the team re-clone. A commit hash they still hold can resurrect the file.

3. Stop it happening again

.gitignore the file and commit a .env.example with the keys but no values.
Laravel reads real values from the environment, so nothing secret needs to be in the repo at all.
Turn on your host's push protection or run a pre-commit scan so a key gets caught before it lands.

The short version

A scrubbed repo with a live key is still a breach. A rotated key with an ugly history is just housekeeping. Rotate first.

Git Hooks That Earn Their Place on a Laravel Project

Sat, 17 Oct 2026 00:00:00 GMT

Hooks live in .git/hooks, which Git does not version. Point core.hooksPath at a folder in the repo so the whole team runs the same ones:

git config core.hooksPath bin/git-hooks

pre-commit: fix style before it lands

Run Laravel Pint against the staged PHP files only, so the check stays fast:

#!/bin/sh
files=$(git diff --cached --name-only --diff-filter=ACM -- '*.php')
[ -z "$files" ] && exit 0
echo "$files" | xargs ./vendor/bin/pint
echo "$files" | xargs git add

pre-push: run the tests that matter

A full suite on every commit is too slow to keep. Run it on push instead, where a failure is still cheap:

#!/bin/sh
php artisan test --stop-on-failure

commit-msg: keep the log readable

Reject empty subjects and very short ones. Everything stricter tends to get bypassed:

#!/bin/sh
subject=$(head -1 "$1")
if [ ${#subject} -lt 10 ]; then
  echo "Commit subject too short - say what changed and why." >&2
  exit 1
fi

Keep them honest

A hook the team bypasses with --no-verify every day is worse than none. Start with these three, keep them under a few seconds, and only add more when a real mistake slips through twice.

Code Review Habits That Keep Main Clean

Thu, 15 Oct 2026 00:00:00 GMT

Review works best when it is cheap.

Keep changes small

Small changes get read. Large ones get skimmed.

Say what and why

A short description of the change and the reason saves the reviewer a guess.

Review quickly

A review that waits a week blocks the next change too.

Shipping a Laravel App From Git

Thu, 15 Oct 2026 00:00:00 GMT

A Laravel deploy is mostly the same few steps each time.

Build from a known commit

Deploy a tag or a commit hash, not whatever is on a branch right now.

Run migrations deliberately

Run them as a step you can see, and know how to roll back.

Warm the caches

Config, route and view caches are part of the release, not an afterthought.