Open-Source Wikis

/

Laravel

/

How to contribute

/

Development workflow

laravel/laravel

Development workflow

This page covers the loop you actually run when iterating on the skeleton: branch, install, run, test, format, push, PR.

Branch

The repo follows the same versioned-branch convention as laravel/framework: each major version has its own branch (13.x, 12.x, 11.x, ...). At any point in time, exactly one of these is the development branch — currently 13.x (see git rev-parse --abbrev-ref HEAD after a fresh clone).

Branch Purpose
13.x Active development — your changes target this
12.x Backports and high-impact bugfixes
11.x Critical/security fixes only (LTS-ish maintenance)
Older Read-only
master Convention only — points at whichever branch is currently active

When opening a PR, target 13.x, not master.

Install (clean checkout)

git clone https://github.com/laravel/laravel.git
cd laravel
git checkout 13.x

composer setup

composer setup (defined in composer.json) runs:

composer install
# copy .env.example → .env if .env doesn't exist
php artisan key:generate
php artisan migrate --force
npm install --ignore-scripts
npm run build

If any step fails, fix it before continuing.

Run

For active development with HMR + log tail + queue listener:

composer dev

That kicks off four parallel processes (php artisan serve, queue:listen, pail, npm run dev) under npx concurrently. Hit Ctrl-C once to stop everything (--kill-others).

Just the web server:

php artisan serve

Code

Drop your changes into the appropriate directory:

Change Where
Adjust a default in a config file config/<file>.php + corresponding entry in .env.example
Update or add a migration database/migrations/
Add a route routes/web.php or routes/console.php
Tweak the welcome view resources/views/welcome.blade.php
Tweak the Vite pipeline vite.config.js
Change CI matrix .github/workflows/tests.yml
Adjust composer dev orchestration composer.json scripts.dev block

When in doubt, look at recent merged PRs for the same area — most changes are small and have direct precedents.

Test

composer test                     # config:clear + php artisan test
php artisan test                  # full suite
php artisan test --filter=Example
php artisan test --testsuite=Unit

Locally on PHP 8.3, 8.4, or 8.5 — pick whatever you have installed; CI runs all three. If you need to run against a different PHP version, the easiest path is docker run -v $(pwd):/app -w /app php:8.5-cli bash -lc "composer install && php artisan test".

Format

Pint comes pre-installed via composer.json's dev requires:

vendor/bin/pint

The .styleci.yml config (preset laravel, no_unused_imports disabled, index.php excluded) is the source of truth. Pint reads it. Run before committing — there's no pre-commit hook bundled, so it's manual.

vendor/bin/pint --test    # exit non-zero if anything would change
vendor/bin/pint --dirty   # only check files modified vs the working tree

Commit

The repo uses descriptive, prefix-friendly commit messages. Looking at recent log entries:

  • Use Vite font plugin for application fonts (#6806)
  • [13.x] Adds pao by default (#6802)
  • Add @no_additional_args to composer test script config clear (#6799)
  • [security] pin axios version (#6776)

Patterns to follow:

  • Optional [<branch>] prefix when targeting a specific maintenance branch.
  • Optional [security] prefix for security-related changes.
  • Imperative mood — "Add X", "Remove Y", not "Added".
  • PR number suffix in parens — added by the merge tooling, not by you.

There's no enforced format. Match the surrounding history.

Push and PR

git push origin <your-branch>

Open the PR against 13.x. The bundled workflow .github/workflows/pull-requests.yml runs on pull_request_target: opened and uses the laravel/.github reusable workflow to set initial PR metadata (e.g. mark unedited PRs).

CI (.github/workflows/tests.yml) runs automatically on push and pull_request. Wait for green across all three PHP versions before requesting review.

Backports

If your fix applies to older branches (12.x, 11.x), the maintainers usually handle the cherry-pick — don't open three PRs. Land on the active branch first.

Dealing with merge conflicts

The repo periodically merges 12.x → 13.x to forward-port shared fixes. If your PR conflicts with a merge that happened after you forked, rebase your branch:

git fetch origin
git rebase origin/13.x
# resolve conflicts
git push --force-with-lease

Most conflicts are in composer.json (version constraints), package.json (Node deps), or CHANGELOG.md. The CHANGELOG.md is regenerated by the update-changelog.yml workflow on each release, so a conflict there is usually fixable by accepting both sides.

Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.

Development workflow – Laravel wiki | Factory