Git Tools Bundle Laravel Package

Getting Started

Read this first: it is a Symfony bundle, not a Laravel package. There is no service provider, no config/git-tools.php, and no facade. SliGitToolsBundle extends Symfony's Bundle class, ships its logic as a DependencyInjection extension plus a set of symfony/console commands, and expects to be wired into a Symfony kernel. If your target is a Laravel app, you are evaluating it as a CLI tool you shell out to, not as something you composer require and use in-process.

Minimal steps to get a first look:

composer require --dev sergeil/git-tools-bundle
# Symfony only — register in config/bundles.php:
# Sli\GitToolsBundle\SliGitToolsBundle::class => ['dev' => true, 'test' => true],
php bin/console list | grep -i git   # confirm actual command names before scripting anything

Where to look first, in this order:

1. README.md — the only documentation that exists; treat it as authoritative but verify against code.
2. Command/ — the real API surface. Command names, options, and exit codes live here, not in the README.
3. DependencyInjection/Configuration.php — the actual config tree keys; the README may be stale.
4. composer.json — Symfony version constraints and the last-supported PHP. This determines whether it runs at all on a modern stack.

First use case: you maintain an app that pulls in several first-party bundles/packages from separate Git repos, and you want one command that fetches/pulls/updates all of them instead of cd-ing into each. Run it once in dry-run/manual mode against a clean checkout before letting it touch a working tree.

If you are on Laravel and still want the behaviour, the pragmatic path is: install it in a throwaway Symfony skeleton (or just read Command/), then reimplement the 30–80 lines you actually need with Illuminate\Support\Facades\Process. That is usually faster than bridging a Symfony bundle into Laravel.

Implementation Patterns

Pattern 1 — Shell-out from an Artisan command. The realistic Laravel integration. Keep the bundle (or a copied script) outside the app and invoke it via a process wrapper so failures surface as non-zero exit codes:

use Illuminate\Support\Facades\Process;

$result = Process::path(base_path())
    ->env(['GIT_TERMINAL_PROMPT' => '0'])
    ->timeout(300)
    ->run('php ../git-tools/bin/console git:update --no-interaction');

$result->throw();

Wrap it in a command (php artisan bundles:update) so it is discoverable, and log $result->output() / $result->errorOutput() rather than swallowing them.

Pattern 2 — Composer script hook. If the tool is invoked from a Symfony-side checkout, expose it as a Composer script ("git:update": "bin/console git:update") so it composes with post-install-cmd / post-update-cmd. Do not hook it into post-update-cmd on a Laravel app — it mutates working trees and will break CI.

Pattern 3 — CI job, not developer machine. The tool's value is batch-updating N repos. In CI that means: a job with a deploy key or GITHUB_TOKEN, a shallow clone, and --no-interaction. Treat every run as destructive-adjacent: run on a fresh checkout, never on a cached workspace with local edits.

Pattern 4 — Config as data. Whatever the bundle's config tree exposes (repo list, branch, remote, working directory), mirror it into a Laravel config file and feed it via env vars so dev/staging/CI differ without code changes. Keep the repo list in one place; the fastest way to get burned is two sources of truth (bundle config + a hardcoded list in a script).

Pattern 5 — Idempotent, verifiable steps. Whatever the command does (fetch, pull, rebase, checkout a ref), assert the resulting state afterward — git rev-parse HEAD, git status --porcelain — instead of trusting the exit code alone. Batch tools that touch multiple repos frequently return 0 with one repo silently skipped.

Gotchas and Tips

Maturity is the headline issue. 0 stars, 0 dependents, and no ecosystem signal means: no Stack Overflow answers, no security advisories, no guarantee of a fix when it breaks. Before adopting, check the commit history date, whether the Symfony constraints accept your current version, and whether the code uses deprecated Symfony APIs (Command::configure() signatures, getContainer() patterns). Budget for vendoring or rewriting.

Laravel/Symfony impedance mismatch. You cannot register the bundle in bootstrap/providers.php. There is no Illuminate\Support\ServiceProvider. Any attempt to "make it work" in-process means pulling in Symfony's DI container alongside Laravel's — a maintenance trap. Shell-out or rewrite; do not bridge.

Non-interactive git auth is the #1 runtime failure. Batch commands hang forever on credential prompts. Always set GIT_TERMINAL_PROMPT=0, prefer GIT_SSH_COMMAND="ssh -o BatchMode=yes", and give the process a timeout so a hang becomes a failure instead of a stuck pipeline.

Dirty working trees and destructive defaults. Any tool that "updates several bundles" likely stashes, resets, or hard-checks-out. Run it on a clean tree first and confirm behaviour; keep git stash list in your muscle memory. Never point it at a directory containing uncommitted work you care about.

vendor/ is not under version control. If the tool pulls into vendor/ (a path or vcs repository), the next composer install/composer update overwrites your changes. Use it for pre-commit source trees, not as a substitute for Composer's VCS repository support.

Command names are not guaranteed. Do not copy command names from a blog post or the README without running php bin/console list. Namespaced commands shift between versions; verify, then script against the verified name.

Exit codes and partial failure. Batch operations tend to be "best effort." Check per-repo output, not just the aggregate exit status, and make your wrapper fail loudly on any skipped repo.

Extension points, if you must extend it. The bundle's DI extension and Configuration.php are where you'd add options; overriding a command means replacing the service definition, which is awkward outside Symfony. This is another argument for copying the relevant command into your own codebase — it is small, and you gain full control over auth, logging, and error handling.