Git Profiler Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for release automation: a package that shells out to the git binary sits in the "release plumbing" layer — tagging, changelog assembly, branch introspection, or commit-based versioning. Adopting it replaces a bespoke internal wrapper and the maintenance burden that comes with it.
• Deployment pipeline design: if the package exposes git operations to the application, it enables release steps (tag-on-deploy, version stamps, generated changelogs) to live in Laravel code rather than duplicated shell scripts across CI and local environments.
• Feature roadmap for admin/ops surfaces: programmatic repo access opens the door to in-app release dashboards, "what shipped" views, and environment version indicators without a separate service.
• Environment portability as a roadmap concern (1.1.0): the new ability to configure the git binary path removes a hardcoded assumption about where git lives. This directly supports decisions to run the same package across containerized CI, Nix-based builds, Windows dev machines, or locked-down images where git is vendored to a non-standard path.
• Support-matrix scoping: the config knob signals the maintainer treats heterogeneous environments as in scope, which reduces the risk of adopting it for teams with mixed developer machines.

When to Consider This Package

Consider it when:

• Your delivery process is Git-centric and single- or few-repo — releases correspond to tags, and changelogs or version strings derive from commit history.
• You are on Laravel/PHP and want release logic in application code, not spread across YAML and shell scripts that drift.
• Your environments are non-uniform: containers with custom-built git, Windows developers, CI images with pinned binaries. The 1.1.0 configuration option is precisely the escape hatch that makes adoption viable here rather than a blocker.
• You want a thin, inspectable dependency rather than a hosted release platform with its own data model and pricing.

Look elsewhere when:

• Your source of truth is a hosted platform (GitHub/GitLab APIs). Native API clients give richer, safer primitives — PRs, checks, protected branches — that shelling out to git cannot express.
• You operate at monorepo or multi-repo scale, where release orchestration needs a dedicated tool (release-please, semantic-release, GoReleaser) and per-repo binary configuration becomes config sprawl.
• Security posture forbids subprocess execution from the application runtime, or the app runs multi-tenant with untrusted input anywhere near a shell invocation.
• Git operations are needed only at deploy time, not runtime — a CI step is the simpler, lower-blast-radius answer.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that removes manual steps from our release process and replaces code we would otherwise write and maintain ourselves. The 1.1.0 release is a minor, backwards-compatible change that lets us point the package at a specific git binary — meaning it works identically on our CI containers, our build images, and developers' laptops. That reduces environment-specific breakage and the support load that comes with it. No migration cost, no vendor lock-in, no procurement.

To engineering: The package wraps git rather than reimplementing it, so behavior matches what engineers already expect from the CLI. Version 1.1.0 adds a configurable binary path, which is the correct fix for the "git isn't on PATH here" class of failures — it keeps the package viable in constrained images and Windows environments without forking. Configuration-only, no API changes, safe minor bump. Worth pinning to ^1.1 and adding a smoke test that exercises the configured path in CI so the new option is actually covered rather than assumed.