- Is sebastian/git-state a Laravel package?
- No. sebastian/git-state is a plain, dependency-free PHP library with no service provider, config file, facade, or published assets, so it does not auto-register in Laravel. It works fine alongside Laravel 10, 11 and 12 when you bind it yourself. The recommended pattern is a small application-owned interface plus a readonly DTO, with the library wrapped in an adapter so third-party types never leak into your domain code.
- How do I install sebastian/git-state with Composer?
- Run composer require sebastian/git-state, or composer require --dev sebastian/git-state if you only need it for CI, deployment scripts, or your test suite. There are no transitive dependencies and no autoload surprises, so installation is a single leaf package. After that, instantiate the Builder class and call build().
- Which PHP version does sebastian/git-state require?
- Sebastian Bergmann packages track current PHP aggressively, so check the constraint with composer show sebastian/git-state before adopting. If the floor sits above your minimum supported runtime across app, CI and legacy services, that is a hard stop. Verify against every environment that will load the package, not just your newest services.
- Why does Builder::build() return false?
- build() returns false both when the directory is not a Git repository and when there is no origin remote configured, so the two conditions are indistinguishable from the return value alone. Those are different operational problems that need different responses, so do not conflate them. Wrap the call in an adapter and enrich the result with your own diagnosis, or accept an explicit unknown state.
- Does sebastian/git-state work in production when there is no .git directory?
- No. The library shells out to the git binary and needs a .git directory, while most production artifacts are built from a tarball or a Docker build context that excludes .git. Slim and Alpine images frequently omit git as well, and hardened hosts often disable exec and shell_exec. Treat it as a CI and deploy-time tool, or inject version metadata at build time instead.
- How do I show the current Git commit and branch in a Laravel app?
- Call Builder::build() in an Artisan command or deployment gate, then read commit(), branch(), originUrl(), isClean() and status() from the returned state object. Cache the result, for example in a config or cache entry written during deploy, rather than rebuilding it per request. Keep the call out of the HTTP request path and out of domain services.
- Is it safe to call sebastian/git-state on every HTTP request?
- No. There is no timeout knob, and a blocking git status on a large monorepo can take seconds, which is unacceptable in any user-facing latency path. The library also assumes .git and an available git binary, which production containers often lack. Resolve the state once at build or deploy time and expose it as cached configuration.
- What causes dubious ownership errors when using sebastian/git-state in Docker?
- Git 2.35 and later refuse to operate on a repository owned by a different user, which happens when a container runs as a non-owner UID. You will see a dubious ownership error and build() may fail or return false. Add the checkout to safe.directory for that user, or ensure the build and runtime UIDs match.
- How do I test Laravel code that uses sebastian/git-state?
- Do not mock the third-party class directly. Define your own interface with a current() method returning a readonly DTO, implement it with an adapter around Builder, and bind a fake implementation in the container during tests. That gives you one testable seam and makes swapping or forking the library a one-file change.
- What are the alternatives to sebastian/git-state for version metadata in Laravel?
- If you only need the revision at runtime, inject it at build time via an environment variable or generated file using CI values such as the commit SHA, which is cheaper and safer than shelling out. Alternatives include running git rev-parse and git status yourself behind a typed wrapper, or relying on your deploy tooling to stamp the artifact. Note that sebastian/git-state has a single maintainer and a small dependent base, though its BSD-3-Clause license and roughly 100 lines of code make forking or vendoring a low-risk fallback.