Getting Started

Install with composer require --dev only if you intend to use it purely for test faking; otherwise install as a normal dependency so the GitManager and its bindings are available in production code paths.
Start by reading the package's service provider — it is the source of truth for how the manager, factory, and drivers are bound into the container. Look for the singleton registration of the manager and the driver resolution logic.
Check the published config file (typically config/git.php or similar) for the default driver and any driver-specific connection/credential blocks. This is where you choose between the real driver and FakeGitDriver.
First use case: resolve the manager from the container (app(GitManager::class)) and pull a driver, or — more commonly — swap the driver to FakeGitDriver inside a test so git operations are deterministic and do not touch the filesystem or a remote.
Because FakeGitDriver was only just restored in v1.11.2, confirm your locked version is >=1.11.2 before writing tests against it; earlier 1.11.x releases will not have it.

Implementation Patterns

Manager-first resolution. Depend on the manager (or its contract) rather than instantiating a concrete driver. The manager handles driver selection from config and caches resolved instances, which keeps your code driver-agnostic and makes the fake swap trivial.
Fake in tests via the manager. In a test's setUp (or a dedicated trait), call the manager's fake/swap method to replace the default driver with FakeGitDriver. Assert against the fake's recorded calls rather than shelling out to real git.
Config-driven driver selection. Point default at the real driver in production and let your test suite override it to the fake. This avoids scattering if (app()->environment('testing')) checks through application code.
Dependency injection over facades. Inject the manager contract into jobs, actions, and services. This keeps fake injection working through Laravel's container and makes unit testing straightforward.
Factory usage for one-off drivers. When you need a driver with non-default config (e.g. a different repository path), use the factory to build it explicitly rather than mutating global config mid-request.
Custom drivers. Register your own driver through the manager's extend-style hook in a service provider. Useful if you need a wrapper around a specific git host or a recording driver with richer assertions than the built-in fake.

Fake in production is a footgun. FakeGitDriver is intended for testing and non-production use only. Guard against it accidentally being the configured default in staging/production — add a config assertion or an environment check in a bootstrap/service provider.
State leaks between tests. The manager caches resolved driver instances as a singleton. If one test swaps in the fake, subsequent tests may inherit it. Reset or re-swap the driver in tearDown, or use RefreshDatabase-style isolation plus an explicit manager reset.
Config caching. If you rely on config to select the driver, remember php artisan config:cache bakes in the value. Changing drivers at runtime after caching requires config:clear or a runtime swap through the manager.
Version pinning. Since the fake was removed and then restored, pin to ^1.11.2 in composer.json to avoid landing on a 1.11.x build without FakeGitDriver. Check composer.lock after upgrading.
Debugging driver resolution. When the wrong driver is used, dump the manager's resolved driver name and the merged config early. The factory/manager layering means the config value, the factory default, and any runtime swap all compete — trace which one wins.
Extension point: the manager's custom-driver registration is the right place to add instrumentation (logging, timing) without touching application code, and it composes cleanly with the fake for hybrid test scenarios.