Code review, CI, planning, and releases.
One product. Not four tabs.

GitHub was built for 2010. GitAxis is built for how developers actually work today — stacked pull requests, fast CI, sprint planning that lives next to the diff, and a codebase that's fully open source. One platform, not a pile of integrations.

gitaxis / gitaxis · pull / 142 files 3 diff checks 12

● OPEN stacked-pr: enforce queue ordering on rebase #142

o odell opened 2h ago · base main ← odell/stack-3 · base PR #141

stack of 4

#140 #141 #142 #143

internal/pullrequests/queue.go +38 −12

104@@ -104,7 +104,9 @@ func (q *Queue) push(ctx context.Context, pr PR) error

104if pr.BaseSHA != q.tip {

105- return ErrStaleBase

105+ if !pr.Stacked { return ErrStaleBase }

106+ if err := q.reorderOnto(ctx, pr); err != nil {

107+ return fmt.Errorf("queue reorder: %w", err)

108+ }

109}

110q.pending = append(q.pending, pr)

shanawasin · 42m · line 106

should this also bump seenAt so the health-check doesn't mark it stale 30s later?

odell · 12m · ✓ resolved

good call. fix pushed, regression test in queue_integration_test.go.

scroll

STACKED PULL REQUESTS

Author small. Land in order.

Split a feature into a chain of small, reviewable slices. The merge queue rebases each PR on top of the latest main, runs CI, and lands them in dependency order — without anyone watching a Slack thread.

▸ Native stack-aware UI. Every PR shows its chain.
▸ Draft-merge gate. Protection rules fan out in realtime.
▸ One keybind walks the diff (j k).

merge queue · gitaxis / gitaxis

main · auto-rebase enabled · 12 jobs · 28s median

live

#140 @odell ✓ merged

split queue interface

+12 −8 · stacked on main

#141 @odell ✓ merged

add q.reorderOnto()

+24 −2 · stacked on #140

#142 @odell ◆ merging

enforce queue ordering on rebase

+38 −12 · stacked on #141 rebasing on main@19ed

#143 @odell ○ queued

regression test for stale base

+18 −0 · stacked on #142

#144 @maia ● in review

docs: stack lifecycle diagram

+64 −4 · stacked on #143

main ✓ green

at gitaxis@a4f2c · CI green for 42 commits

ci · run #2,847 · main summary jobs 12 timing

7 of 12 · 00:00:34 elapsed

✓ gofmt 0.4s
✓ go vet ./... 2.1s
✓ go test ./internal/auth/... 3.8s
✓ go test ./internal/catalog/... 5.2s
✗ go test ./internal/pullrequests/... 8.7s
--- FAIL: TestQueue_RebaseStacked (0.41s)

queue_integration_test.go:142: stack head not updated

expected: q.tip == "abc123"

actual: q.tip == "ffe092"

FAIL gitaxis/internal/pullrequests 8.741s
… go test ./internal/issues/... running
○ svelte-check queued
○ e2e (chromium) queued
○ e2e (firefox) queued
○ docker build queued
○ publish artifacts queued

R rerun all F rerun failed only o jump to failure cached layers from main@a4f2c

CONTINUOUS INTEGRATION

CI in seconds. Failures collapse to the file.

NVMe storage and hot caches by default. The log surface jumps you to the failing assertion — not page-five of an unstructured dump. Rerun just the failures with one keystroke.

▸ Job-level parallelism. Defaults to aggressive.
▸ Live streaming logs. Passes collapse, failures expand.
▸ Rerun-failed-only is a primary action, not a buried menu.

MAINTAINER CONTROL

Run open source with an actual control surface.

Maintainers need triage, review state, CI signal, contributor history, and fast moderation decisions in one place. The workflow should feel closer to a control panel than a pile of tabs.

▸ Triage queues built for maintainers, not just contributors.
▸ Review, CI, and contributor context on the same surface.
▸ Faster decisions without chat-tab archaeology.

~ / inbox 12 unread

All Mine Watching archive · 384

✓ m @maia merged gitaxis#138 stacked-pr: rebase on top of #137 2m
▲ r @rafa requested changes on gitaxis#142 still missing the regression test 12m
● o @odell opened gitaxis#142 enforce queue ordering on rebase 2h
✗ c ci failed on gitaxis@e3f2a91 TestQueue_RebaseStacked 3h
◆ b @bex @-mentioned you in gitaxis#139 reviewing protection-rule fan-out 5h

jk navigate ↵ open e archive 123 scope

sprint 14 · 2 days remaining ✓1 ◐2 ○2 ⊘1

1 of 6 done · 4 in flight · 50 days saved

	ID	title	pri	who	due
◑ in review	GIT-142	enforce queue ordering on rebase	P1	o	today
◐ in progress	GIT-143	regression test for stale base	P1	m	today
✓ done	GIT-138	split queue interface	P2	o	fri
⊘ blocked	GIT-145	realtime fan-out for protection rules	P0	r	mon
○ todo	GIT-146	docs: stack lifecycle diagram	P3	b	—
○ todo	GIT-147	inbox: collapse bursts from one author	P2	m	wed

PLANNING

Plan the sprint where the pull requests actually land.

Issues, sprint views, and manager-facing planning stay in the same system as code review and CI. Work does not disappear into a separate tracker the moment implementation starts.

▸ Org and manager views built around actual engineering flow.
▸ Issues, PRs, and CI status stay connected by default.
▸ Sprint planning without context loss between tools.

NATIVE WORKFLOWS

Keep your workflow syntax. Lose the drag.

Compatibility matters when teams move. The goal is a better platform without forcing every team to rewrite its delivery muscle memory first.

▸ Familiar workflow format.
▸ Less friction to try the platform.
▸ Migration without ceremony.

📁 .gitaxis/workflows · 4 files ✓ github actions yaml runs unmodified

✓
test.yml

push · pull_request

28s ago · 412ms median
✓
deploy.yml

on: release

4h ago · 1m 12s
✓
nightly.yml

cron 0 2 * * *

12h ago · 2m 04s
◆
ci.yml

imported · .github/workflows/ci.yml

running · 18s
imported

test.yml

name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: gitaxis-nvme
    steps:
      - uses: actions/checkout@v4
      - run: go test ./...

drop-in compat · actions/* & setup-* steps reuse the marketplace cache

gitaxis · NVMe + hot cache 28s same job on stock github runners 4m 17s

G → ◆ migrate from github · 3 of 4 live · 2 in flight

✓ Connect

✓ Select repos

◆ Migrating

○ Verify

✓
github.com/pmd_dev/dotfiles → gitaxis/pavanmanish/dotfiles
done · 42s

18 prs · 12 issues · 482 commits
◆
github.com/pmd_dev/gitaxis-cli → gitaxis/pavanmanish/gitaxis-cli
importing issues · 18s left

41 prs · 28 issues · 1,284 commits
◆
github.com/pmd_dev/blog → gitaxis/pavanmanish/blog
cloning history · 1m left

6 prs · 4 issues · 318 commits
○
github.com/pmd_dev/notes → gitaxis/pavanmanish/notes
queued

65 prs · 44 issues · 2,084 commits imported history preserved · authors mapped

GITHUB IMPORTS

Move without losing your history.

Switching fails when migration is painful. Gitaxis is built to bring over repositories, issues, pull requests, comments, releases, and authors cleanly.

▸ Repository and metadata import.
▸ History preserved instead of flattened.
▸ Lower switching cost for teams.

PREVIEW ENVIRONMENTS

Every pull request ships a live URL.

Preview deployments belong in the review flow, not in a separate platform. Open the branch, inspect the UI, compare it to main, and decide faster.

▸ One preview per PR.
▸ Logs and checks next to the diff.
▸ Faster feedback before merge.

https:// pull-142-q9k2.gitaxis.dev

✓ Ready · 42s

pull-142-q9k2.gitaxis.dev

build 12s cached layers · 2 of 14 rebuilt
deploy 28s edge cdn · 18 regions
cold start 280ms go binary · single replica

lighthouse

perf

100

a11y

seo

best

e3f2a91 enforce queue ordering on rebase

⌕ q.push▍ ⌘+⇧+F

4 of 1,284 matches · 18ms

func gitaxis/gitaxis · internal/pullrequests/queue.go :104

104func (q *Queue) push(ctx context.Context, pr PR) error {

func gitaxis/gitaxis · internal/pullrequests/queue.go :168

168func (q *Queue) pushBatch(ctx context.Context, prs []PR) error {

test gitaxis/gitaxis · internal/pullrequests/queue_integration_test.go :88

88func Test_Queue_PushFlatPR(t *testing.T) {

cmd pavanmanish/gitaxis-cli · cmd/queue/push.go :14

14cmd := &cobra.Command{Use: "push", Short: "send a PR to the merge queue"}

↑↓ walk · ↵ open in tree indexed 4,127 symbols across 12 repos

CODE SEARCH

Search code like the repo actually matters.

Symbol, semantic, and literal search should feel instant. Developers should not have to lower their expectations because the codebase got large.

▸ Fast code and symbol lookup.
▸ Built for real repository depth.
▸ Search that keeps review momentum.

SECURITY

Security should be part of the flow, not an upsell.

Secrets, dependency risk, and attestations belong inside the same developer loop as review and CI. OSS should not be second-class here.

▸ Secret scanning in the normal path.
▸ Dependency alerts with context.
▸ Better defaults for public repos.

⚿ security · gitaxis/gitaxis scanning

critical · fixing

high

med · blocked

resolved · 24h

CRIT ⊞
CVE-2026-0142 in lodash@4.17.20

go.sum · web/package.json

◆ auto-PRing fix
HIGH 🔑
AWS access key

test/fixtures.go:48

✓ rotated 2h ago
MED 🔑
GitHub PAT in .env.example

pull/145 — blocked merge

● 12m ago
LOW ⊞
CVE-2025-9981 in marked@4.1.0

apps/web/package.json

✓ patched 1d ago

✓ attestation v1 · auto-rotate enabled free for OSS · no per-seat

▣ packages · gitaxis/gitaxis org-scoped · private allowed

4 packages

◆

@gitaxis/cli

command-line client for the gitaxis platform

v1.4.2 latest · 2 days ago

$ npm install @gitaxis/cli

weekly downloads

24,182

▲ 12% vs last week

size

142KB

gzip · 0 runtime deps

audit

0vulns

signed · attestation present

recent versions

1.4.2 fixes queue.seenAt 2 days ago latest
1.4.1 reorderOnto() 1 week ago stable
1.4.0 split queue iface 3 weeks ago
1.3.7 legacy queue 2 months ago archived

PACKAGE REGISTRY

Ship code and packages from the same place.

Repositories and artifacts should not feel like different planets. Publish under the same org, keep provenance tighter, and reduce tool sprawl.

▸ Private and public package flows.
▸ Closer build-to-release chain.
▸ Less artifact-tool overhead.

RELEASES

Release notes that understand what shipped.

Releases should be a continuation of review history, not a separate editorial task built from memory and copy-paste.

▸ PR-linked release flow.
▸ Cleaner changelog generation.
▸ Less manual release bookkeeping.

▼ releases · gitaxis/gitaxis latest

v1.4.2

queue ordering

main@b1c8a3f · 2 days ago · ⚿ signed

claude drafted these notes from 6 merged PRs · 8s

◆ Features

· Stacked PRs now reorder on rebase without manual intervention. #142 @odell
· Inbox burst-collapse turns 10 events from one author into 1 row. #147 @maia

✓ Fixes

· Health-check no longer marks reordered PRs as stale 30s later. #142 @odell
· Protection-rule fan-out re-runs on settings change instead of next push. #139 @bex

· Internals

· Queue interface split into push / reorder / advance. #140 @odell
· Integration tests cover stale-base path explicitly. #143 @maia

◆ thread · pull/142 · 3 replies pinned to #142

@shanawasin 12:42

q.seenAt = time.Now()

pinged you here so it stays with the PR — the reorderOnto path is missing the seenAt bump, right?

@odell 12:48

just pushed it. health-check stays happy now.

@rafa 12:55

thx. approving once CI is green.

@ reply to thread▍ ⌘+↵

TEAM THREADS

Talk where the work is happening.

Developers keep losing context to chat tabs. Threads tied to pull requests, issues, and commits keep the conversation attached to the work.

▸ Discussion anchored to code objects.
▸ Less Slack archaeology.
▸ Better coordination around changes.

DOCS

Documentation that lives with the codebase.

Docs should stay closer to changes, releases, and code ownership. Treat them as part of the workflow instead of an abandoned side tab.

▸ Docs tied to repository history.
▸ Easier traceability from docs to code.
▸ Fewer stale wiki islands.

📖 wiki · gitaxis/gitaxis live · linked to commits

⌕ merge queue▍ /

architecture › merge queue

Merge queue

linked to b1c8a3f · last edit 2 days ago by @odell

The merge queue takes accepted PRs and lands them on main in dependency order. Each PR is rebased on top of the latest main, runs CI, and merges only if the run is green.

Stacked PRs reorder automatically via q.reorderOnto() in queue.go:104.

Lifecycle

1 Author opens PR → q.push() enqueues.
2 Queue rebases on main, runs full CI suite.
3 On green, merge writes new tip and notifies subscribers.

internal/pullrequests/queue.go b1c8a3f

func (q *Queue) push(ctx context.Context, pr PR) error

◆ @pavanmanish · profile + follow

Pavan Manish @pavanmanish

Building gitaxis. Tired of waiting on CI.

building gitaxis · joined Jan 2026 · BLR, IN

repos

public · 8 private

482

merged PRs

last 12 months

1.2k

reviewed

across 12 repos

482 contributions in the last 16 weeks less more

featured

▸ gitaxis/gitaxis ★ 412

open-source code hosting platform

go · updated 2d ago
▸ pavanmanish/gitaxis-cli ★ 84

cli client for gitaxis

go · updated 2d ago
▸ pavanmanish/dotfiles ★ 22

my zsh + tmux + nvim setup

shell · updated 2d ago

PROFILES

A profile built around actual development work.

Contribution should be visible through real artifacts: merged pull requests, maintained projects, and work that mattered.

▸ Work-centric profile surfaces.
▸ Better OSS discovery.
▸ Less noise, more signal.

AI REVIEWERS

AI inside your review rules, not outside them.

AI should participate in the same workflow humans use, with the same merge gates and review structure instead of a detached side channel.

▸ AI in the real review surface.
▸ Same guardrails as human review.
▸ Help without workflow drift.

claude · review · pull/142 active

claudecode-review

Read the 3-file diff (+62 / −18). Three findings — one suggestion you can apply in place, one note, one piece of praise.

◆ Bump q.seenAt after reorder internal/pullrequests/queue.go:106

The health-check uses seenAt to mark stale entries. Without the bump the reordered PR can be reaped 30s later.
```
+	q.seenAt = time.Now()
```
● Regression test covers happy path only queue_integration_test.go:142

TestQueue_RebaseStacked asserts q.tip but not the seenAt bump above. Worth adding a subtest.
✓ Error wrap looks good internal/pullrequests/queue.go:108

fmt.Errorf with %w preserves the stale-base sentinel — downstream queue.recover() still works.

3 findings · same approval rules as humans claude cursor

⌘K · command palette esc to close

› go to file: queue▍ ↵

▸ internal/pullrequests/queue.go ▎file · go
▸ internal/pullrequests/queue_integration_test.go ▎file · go
▸ internal/ci/queue.go ▎file · go
commands
⌘ switch repo… g r
⌘ new pull request c p
⌘ jump to inbox g n
⌘ cheatsheet ?

↑↓ walk ↵ open ⇥ filter type indexed 4,127 symbols · 0.6ms

KEYBOARD FLOW

The interface should move at developer speed.

Every surface in GitAxis is built for people who live in their tools. Dense information, fast navigation, and no click-tax for actions you take fifty times a day.

▸ Faster navigation once you are inside.
▸ Dense surfaces without dead weight.
▸ Built for people who live in the tool.

Frequently asked

We get these a lot.
Here are the honest answers.

Yes. The MVP lives on the platform itself at /gitaxis/gitaxis — you can browse the source, read the issue tracker, and watch how it gets built. We are intentionally developing in the open.
The platform hosts its own source code and the team uses it daily. We are opening access in controlled waves to keep quality high — the waitlist is the queue. You can browse the live codebase at /gitaxis/gitaxis right now.
Gitaxis is opinionated around the full developer loop instead of being a code host with disconnected add-ons. Review, CI, planning, maintainer control, and migration paths are treated as one product.
Yes. Single Go binary, Postgres, Redis. That is the entire dependency list. Run it on a NUC, a VM, or a fleet behind a load balancer — the same release artifact serves all three.
The landing now shows the whole product in one features flow: review, CI, planning, maintainer control, deployment, search, migration, packages, releases, communication, and docs.
Because almost no one else does. Every new platform we look at is optimised for agents to read code or for managers to report on it. Gitaxis is for the people whose hands are on the keyboard. The AI features come later — and they will fit into the workflow, not replace it.

Join the waitlist.
See the product when it opens.

Gitaxis is invite-only right now. Leave your email and we will open access in waves while keeping the product stable.

Contact