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 setupcomposer 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 buildIf any step fails, fix it before continuing.
Run
For active development with HMR + log tail + queue listener:
composer devThat 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 serveCode
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=UnitLocally 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/pintThe .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 treeCommit
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-leaseMost 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.