Show repositories, history and pull requests in your product
Provider-neutral Git surfaces — GitHub, GitLab or Bitbucket.
The problem
Your product needs to show what changed: a history, a diff, a pull request. So you integrate with GitHub — and now GitHub's shapes are in your domain model, and supporting GitLab means a second integration that is similar enough to look shareable and different enough not to be.
Meanwhile anything that writes to a repository is a mutation on someone else's source of truth, which is not a thing to do on a model's say-so.
What you are building
Live surfaces, not screenshots — every one composed from the same components you would install.
Repository surfaces
Commit history and working tree from fancy-git-ui — provider-neutral, so the same UI fronts GitHub, GitLab or Bitbucket.
- added
- modified
- untracked
- modified
The code
// The provider adapters normalise GitHub, GitLab and Bitbucket to the SAME
// shape, so the surface above does not branch on which host a repo lives at --
// and adding a host is a package, not a rewrite.
$prs = Git::provider($repo->host)->pullRequests($repo->fullName);
return Inertia::render('Repo/Show', [
'commits' => Git::log($repo->path, limit: 50),
'status' => Git::status($repo->path),
'reviews' => $prs,
]);How to solve it
Install the headless core
Git operations plus a normalized provider contract, so a repository looks the same to your code whichever host it lives on.
Run thisbash composer require particle-academy/fancy-gitAdd the host adapter you need
GitHub, GitLab and Bitbucket ship as separate adapter packages in both languages. Adding a second host is adding a package, not a parallel integration.
Render the surfaces
Controlled, provider-neutral components for repository, history and pull-request views.
Run thisbash npm install @particle-academy/fancy-git-uiKeep writes proposal-first
The Git bridge exposes reads directly, but mutations are proposals a human confirms. An agent can prepare a commit or a review; a person decides whether it lands.
