Hi HN!
I’m Tomas, co-founder of graphite.dev, and today we’re launching Graphite after almost two years of development in closed beta. [1] Graphite started as an internal solution to our own problem. When we (engineers from Meta, Google and Airbnb) left our previous roles, we lost access to the internal code review tools we loved. So we built our own.
https://graphite.dev
---
Graphite is how the fastest developers ship code - it’s a developer tool that allows you to create smaller pull requests, stay unblocked, and ship faster with “stacking” (creating a set of dependent pull requests). Stacking [2] allows developers to break up large pull requests (PRs) into smaller ones that can be reviewed & merged independently, while keeping ongoing development unblocked. Engineering best practices at Google advise that a “reasonable” PR be around 100 lines, and recommend splitting PRs in order to achieve this through stacking or other methods. [3]
Unlike other tools like Phabricator, Gerrit, or Sapling, Graphite syncs seamlessly with your GitHub repositories, so that you don’t have to manage any extra infrastructure. This also means that even if your teammates don’t use Graphite yet, you still can.
Here’s what you can expect when you sign in to Graphite with your GitHub account:
(1) First class support for stacking: At its core, Graphite enables “stacking”—a workflow used by engineers at top companies like Meta and Google to create small, dependent sets of pull requests. The Graphite CLI, web app, and VS Code extension all come together to empower engineers to start stacking.
(2) Pull request inbox: You can think of this as your home page on Graphite, where you have full visibility into the status of all your PRs and know what still needs to be done across every repo, author, and stage of review. You can also create custom inboxes that filter PRs on reviewers, authors, labels, CI status, and more.
(3) Streamlined code review interface: Graphite’s pull request page removes tabs and minimizes distractions, with the aim of putting your code front and center. You can use keyboard shortcuts to navigate between files and comments or to move between PRs in your stack. You can also import custom memes and gifs to add some to your reviews too!
(4) AI-powered pull requests: Auto-generate a detailed description for every PR with our OpenAI integration. You can even turn your comments into suggested code changes (coming soon!).
(5) Real-time notifications: Connect Graphite to your Slack workspace to stay up-to-date on review requests, comments threads, merge status, and other activity on your PRs. For smaller PRs, you can leave a review (and even merge) directly from Slack.
(6) Stack-aware merges: Since Graphite is built to support a stacking workflow, it automates the manual work of rebasing PRs when it’s time to merge. You can merge your stacks with one click from the web app, or in a single command from the CLI.
Feel free to take a look at our getting started guide [4] or product tour video [5] for a tutorial on how to get started, and drop your comments to us below!
[1] http://graphite.dev/blog/launch
[2] http://stacking.dev
[3] https://google.github.io/eng-practices/review/developer/small-cls.html
[4] https://graphite.dev/docs/getting-started-with-graphite
[5] https://www.youtube.com/watch?v=sBcd9uopLOY
Github Enterprise - while of course not 1-to-1 comparable - offers so much more functionality for 2/3ds of the cost of Graphite. I'd expect Graphite to cost _less_ than Github Enterprise as it seems it could be positioned more as an add-on to what you get from Github.
Am I missing something?
So firstly, we have and will continue to have a free tier where anyone can use Graphite for free and get the benefits of the stacking workflow.
Secondly, we have a lot of companies like Ramp who have seen a real gain in productivity from their team and think that the features and benefits of the Graphite Team tier is worth paying for (you can see our customers and case studies on our website).
Lastly and most pragmatically, we need to ensure we have a sustainable business model because we ultimately want to continue bringing word-class devtool features to all of our users.
We encourage you to sign up and try it out. Hopefully you’ll find that the productivity gain is worth the $1 a day. If not, that’s cool too, hopefully we can continue building and improving our product offering so that you check us out again in the future and change your mind.
- Xiulung (Design @ Graphite)
Every single feature of Graphite’s workflow is optimized around stacking, including: - Beautiful code review interface - PR inboxd - Stack-aware merge queue - Team insights - Integration with your favorite tools like Slack and VS Code
Graphite is scalable, and is built for professional software development. Give it a try for free to see for yourself :)
I work for a startup that is less than 3 years old and has ~90 employees of which ~50 are software engineers and data scientists (people writing code). We're VC funded and not profitable yet. When I see a pricing tier called "Enterprise", I do not expect to fall under that tier as a small, young company. But looking at the limits of the Team tier, we would probably not fit under that tier because we have more than 30 repositories. We also use Github Enterprise (cloud version), which puts us in your Enterprise tier as well.
If the Team tier is already $30/user/month, I'm afraid to even learn what the Enterprise tier is like. I guess we're not your target audience and that is okay.
Here is when I would consider paying for your product: remove the repo limit (or make it much bigger) and half the price. That would make it affordable and more in line with the other tools we're paying for.
Hearing about your company size and setup, you're actually in our team plan's sweet spot. If you give it a shot, reach out and let us know what you think!
If you need GitHub Enterprise Server support (eg. on-prem) then that would require our Graphite Enterprise tier...
Typing this out I realize this is confusing and will reconsider the naming of our tiers.
Why is this at all surprising? If you're using GitHub Enterprise, why wouldn't you be using the Enterprise tier of other software?
Does anyone know if you need Graphite to see a PR once it's been merged in the Github repo? I'm curious about how locked you in when you start using Graphite.
Graphite syncs bidirectionally with GitHub so that you can see the same information in realtime across platforms. This also means you can use Graphite even if the rest of your team isn't yet!
All PRs will be shown with the proper draft/open/closed/merged states on GitHub and on Graphite, we do a lot of work to make sure that the real-time status is synced between the two so that you can adopt Graphite without disrupting your team's existing workflow.
Would love to know other pain-points you have around GitHub so that we could make Graphite even better for you and your team
What about the comments on commits? Are those all displayed in the Github PR when it's merged, and attached to all the correct lines, even the ones that were made on branches that were rebased?
Thanks!
One thing that's been a bit annoying: my org enforces signed commits, and when you merge a stack, they sometimes rebase commits internally and lose the code signing, so you end up with an error to merge the rest of the stack.
Aside from that, working with stacks has been great!
Thank you for using Graphite and your support. This is something we're aware of and current thinking around.
Question, if we were to support this by signing commits: Would you want the commit to be signed by the Graphite GitHub App? Or would you prefer for it to be signed by Graphite on behalf of you? Or some other option that we haven't considered?
-Xiulung (UX @ Graphite)
The command name change will take some time to get used to, though!
I've run into a bug with 1.0 where it tries to query git for an object (something with ^tree) that it doesn't understand. I think I'm on a high enough git version, but that could be my issue.
https://join.slack.com/t/graphite-community/shared_invite/zt...
Reach out to me (Jacob Gold) on our Slack Community if you're still seeing this issue. The link's on the Graphite website.
While I'm at it, will there be a setting to automatically delete branches after merging (on app.graphite.dev)? Without manually deleting all branches after a merge, `repo sync` (or just `sync` now, I suppose!) doesn't pick up that a branch has been merged.
If you want to 1. multiply developer velocity 2. attract the best technical talent, use Graphite.
- Xiulung (UX @ Graphite)
I would be happy for someone to prove me wrong and show how, e.g. `git branchless` lets you work on a stack from multiple machines.
Stacking was a meaningful time-saving as a FAANG sw eng. Excited to see stacking grow within the great tech community
Graphite is a god send in my post FB career!
Agreed! We think this is a huge performance boost and why we think any engineer should benefit from stacking!
What benefit does Graphite provide further?
Main pain point I imagine is dealing with rebases? What else?
In addition, in our code review interface we provide the ability to see and review PRs in the stack context so reviewers can see and understand what the dependencies are, we have the ability to merge a stack (in full or in part) automating the process of any rebases that need to happen between merges, and we also have a merge queue that is stack-aware which makes sure that PRs added to the merge queue are merged in order while ensuring that everything merged into the main branch has passed tests.
Depending on your org's GitHub settings, using stacks can be a pain because the branch protection rules aren't always clear when you're looking at a PR that is stacked indirectly on a protected branch. In those cases, you may find that as you merge your stack in order, additional blockers get added. Graphite helps to show you these requirements ahead of time so that you can make sure your PRs are actually ready to merge before you start merging.
What are some pain points you or your team face?
A lot of the benefits remind me of other dag-based workflows, like CI, data pipelines, or build systems. Does that make sense?
tl;dr the difference is a stack is merged partially as it's built out (that reduces merge conflicts, allows you to revert individual parts as found) and a feature branch is long-lived. Hope that helps :)
-Xiulung (UX @ Graphite)
Stacking makes this all easy by allowing you to make smaller sets of dependent PRs so you can stay unblocked and merge into trunk more often.