Paste a public GitHub repo and draw its commit graph in your browser, or compare GitFlow, GitHub Flow and trunk-based branching side by side.
Paste github.com/owner/repo and this tool fetches that repository’s recent history and draws it as a railway–style commit graph: one coloured lane per line of development, a dot per commit, hollow dots for merges, and branch tips labelled where they land. The commit list runs alongside the graph, row–aligned, so a shape in the drawing and the message that produced it are on the same line.
There is a second mode for people who arrived to learn rather than to inspect: a side–by–side comparison of GitFlow, GitHub Flow and trunk–based development, each with its own diagram, the branches it uses, how long each is meant to live, the workflow in order, and a copyable command sequence.
The repository graph is built entirely in your browser. When you press the button, your browser calls GitHub’s public REST API directly and draws the result. Nothing is proxied through this site, no clone happens, nothing is written to a server, and no account is involved on either end.
That is not a privacy slogan, it is a description of the network traffic, and you can confirm it: open your browser’s developer tools, switch to the Network tab, and watch the requests. Every one of them goes to api.github.com. There are no calls to this domain while the graph is being built.
This tool has real constraints. They are not arbitrary, and they are not oversights. Each one follows directly from the decision to run without a server, so it is worth understanding what you get in exchange.
| Limit | Why |
|---|---|
| About eight repositories per hour | GitHub allows 60 unauthenticated API requests per hour per IP address. Drawing one repository costs roughly seven of them — one for the repository itself, one for the branch list, and one per branch whose commits are read. |
| Public repositories only | Reading a private repository requires a personal access token. Collecting other people’s tokens is a responsibility this tool declines to take on. |
| Recent history, not the whole graph | The API returns commits a page at a time. A repository with fifty thousand commits would need hundreds of requests and would exhaust the hourly allowance on a single view. |
| The busiest few branches | Every branch read costs another request. A repository with two hundred branches cannot be drawn in full within the allowance, so the default branch and a handful of others are used. |
| GitHub only | GitLab and Bitbucket expose comparable APIs with different shapes and different authentication rules. Supporting them properly is separate work rather than a small change. |
The 60–per–hour figure is what GitHub grants an anonymous caller. A server holding an API token would get 5,000 requests an hour instead — roughly eighty times more headroom, and no visible limit for most people.
The catch is what that architecture requires. A server–side token means every repository you look up is a request made by this site rather than by you. The lookups would pass through our infrastructure, appear in our logs, and be attributable to our token. For a tool whose entire job is reading source–control metadata, that is a meaningful change in who knows what you are looking at.
Running anonymously from your browser avoids all of it. The request comes from your IP, under your own allowance, and this site never sees which repository you asked about. The cost of that is a modest hourly cap. It is a deliberate trade, and for a tool used a few times rather than all day it is the right way round.
You will see a message saying the rate limit has been reached, not a blank screen or a broken graph. The allowance resets on the hour. Two things soften it in practice: repositories you have already drawn are cached for the rest of your browser session and cost nothing to view again, and the remaining request count is displayed above each graph so you can see how much headroom is left before you run out.
If you share an office network, be aware the limit is counted per IP address. A colleague using the tool from the same connection draws from the same 60.
Every commit sits in a lane, and the lane is the point. A lane is a continuous line of development, not a named branch — Git does not store which branch a commit “belongs to”, only which commits precede it, so the lanes are reconstructed from the parent links.
The rule that makes the picture readable is first–parent continuity. Every commit records its parents in order. A commit takes over the lane that was waiting for it, and its first parent continues in that same lane, which is what keeps a branch running as a straight vertical line rather than wandering across the diagram. When a merge commit has a second parent, that parent opens a lane of its own, and the curve joining them is the branch you merged in.
A merge preserves the fact that work happened in parallel: two lanes run side by side and rejoin at a hollow dot. A rebase rewrites those commits onto the tip of the target branch, so the parallel lane disappears and the history reads as a single straight line. Neither is more correct, but they are visibly different, and a graph is the fastest way to see which convention a project actually follows — regardless of what its contributing guide claims.
A repository with a long unbroken trunk and short stubs merging in is practising something close to GitHub Flow or trunk–based development. One with a permanent second lane running in parallel to the trunk is running something GitFlow–shaped. That is usually more informative than reading the documentation.
The second mode compares the models most teams are choosing between. Each has a diagram showing the actual topology, not just a list of branch names.
Two permanent branches, main and develop, with feature branches merging into develop, release branches cut from it for stabilisation, and hotfix branches taken from main. The detail people get wrong is that a hotfix merges to both main and develop — miss the second merge and the fix is silently lost at the next release. It suits scheduled releases, multiple supported versions, and formal QA. It is heavy for teams shipping continuously.
One permanent branch. Short feature branches are cut from main, reviewed, and merged straight back, with each merge deployable. Far less ceremony, and it depends on the tests and review being good enough that main is always releasable.
Small commits landing on the trunk continuously, with branches living hours rather than weeks. Long–lived branches are treated as the problem to avoid, and incomplete work is hidden behind feature flags instead. It demands strong automated testing and is the model most associated with high deployment frequency.
Because this reads recent history rather than the whole repository, and because it draws a handful of branches rather than all of them. A desktop client with a full local clone sees everything. This is for a quick look at a repository you have not cloned.
Not through this page — it reads the GitHub API, not your disk. Locally, git log --graph --oneline --all draws the same structure in the terminal, using the same first–parent rule.
No. The requests are anonymous, so your GitHub session is irrelevant to them. Private repositories require a token attached to the request, which this tool does not ask for.
GitHub Flow is ideal for small teams. It uses just main plus short-lived feature branches, with deployments happening from main after each merge. Teams of 2-10 developers typically find this provides enough structure.
GitFlow uses multiple long-lived branches (main, develop, release, hotfix) for scheduled releases. GitHub Flow uses only main plus feature branches for continuous deployment. GitHub Flow is simpler but GitFlow provides more release control.
Trunk-based development means all developers commit directly to main or use very short-lived feature branches (less than 1 day). It requires excellent CI/CD, feature flags, and automated testing.
Short-lived feature branches (1-3 days maximum) are strongly preferred. Long-lived branches lead to painful merges and integration issues. Use feature flags to merge incomplete work safely.
Consider release cadence, team size, and deployment practices. For continuous deployment with a small team, use GitHub Flow. For scheduled releases, use GitFlow. For high-velocity teams, consider trunk-based.
Feature flags are runtime toggles that hide incomplete features in production code. They're essential for trunk-based development and useful for A/B testing and gradual rollouts.