How to recreate the Phabricator code review workflow

When the Phabricator team discontinued development in 2021, they left a huge void in the developer tool space. Many big tech teams had all come to depend on the code review workflows Phabricator introduced. While you can continue to use the legacy platform, it makes sense to transition your team out of the system slowly.

The core principles of Phabricator still matter greatly—flexible draft changes, feedback before merging, and controlled releases. However, recreating that workflow to align with modern teams' operations isn’t easy and can require heavy lift from engineering teams.

Today's developers need easy context sharing across GitHub, Slack, and their IDEs of choice. The self-hosted Phabricator approach was practical at the time, back when it was actively maintained, and before the advent of more modern integrated ecosystems, but it no longer aligns with the current engineering workflow.

If you're moving away from Phabricator or looking to evolve its efficient workflow, this article is for you. We'll explore how to recreate the Phabricator code review system with a modern, integrated toolstack that leverages today's leading development platforms.

What is the Phabricator workflow?

Long before "pull request driven development" became popularized, Phabricator pioneered a write → review → merge → publish paradigm for peer collaboration. This approach contrasted sharply with alternative workflows that immediately publish changes externally for wider visibility.

Core principles of Phabricator's workflow

The Phabricator workflow was based on several core principles. Here are three important ones:

Treat changes like flexible drafts

Phabricator reinforced the idea that local changes should be viewed as malleable documents for exploration rather than permanent. This idea is similar to how an author's initial draft can change and improve with feedback from an editor before it's finally published.

The whole system created a psychological safety for developers to freely experiment with solutions from various angles before framing polished commits for review. The pressure to immediately market "the right take" was no longer present.

Teams had the space to express what they didn't fully grasp yet and to incubate vulnerable, unconventional ideas that may have otherwise been hidden away due to the demand for perfection.

Review diffs, not branches

Phabricator concentrated feedback on smaller sets of code diffs, reflecting incremental work-in-progress changes rather than monolithic feature branches. The result? Discussing the implementation and evaluating alternate approaches became more transparent instead of packaging everything formally every time.

Conversations focused on subtle architectural tradeoffs and future unknowns. Developers also avoided the anxiety-inducing practice of defending ambiguous technical changes.

Merge first, then publish

Phabricator deferred the external publication of changes until after they proved useful enough for integration into the team's central branches.

Phabricator pioneered the code review process, meaning changes required genuine peer reviews and endorsements before broadcasting widely.

Together, these principles cultivated an environment optimized for collaboration and feedback.

The core Phabricator workflow

The resulting workflow sequence looked like this:

1. Write: Developers made local changes, committing frequently without concern for formal polishing. The checkpoints enabled deeply creative exploration.

2. Review: Related commits were bundled into "Differential Revisions" for internal feedback within the team's shared context. Discussing these specifics reinforced collective wisdom—without the fear of judgment.

3. Merge: Once technically approved through peer review, the revisions were merged into the main branch for shared integration and staging. The branching conversation focused on a collective understanding of the code and its future impact.

4. Publish: Finished features were published externally as seamless, fast-forwarded commits consumable by less informed stakeholders. Since the team approved all the code diffs, there was enough data for stakeholders to approve the main merge.

Why recreate the Phabricator workflow?

Phabricator workflows improved how teams worked together. However, since Phabricator is no longer maintained, many teams that worked on this platform need a Phabricator alternative to recreate this workflow. You may as well be a new team looking to explore a new way to work and speed up development.

The Phabricator workflow has multiple benefits

Some of the key benefits of Phabricator included:

• Lightweight code reviews: Open communication allowed developers to receive feedback early and often instead of right before finishing features. Therefore, people were more willing to take risks and learn faster.

• Focused conversations: Feedback centered around small specific changes rather than big finished products, which kept discussions focused on technical details instead of presentation polish.

• Controlled integration: Required changes to be accepted internally before making them externally visible and helped build more collective buy-in.

• Integrated platform: Provided a suite of integrated tools for developers under one roof that enabled smooth hand-offs between previously disconnected systems.

These thoughtful practices increased transparency, alignment, and productivity when used properly.

To preserve the philosophy

Simply replacing Phabricator with a like-for-like clone misses the bigger opportunity.

A better approach is to:

1. Keep the helpful cultural philosophies that powered Phabricator's workflows.

2. Improve technical constraints using modern technologies available at hand.

This balance enables you to sustain and enhance the development practices that worked well without being limited by outdated legacy implementations.

The goal is to stay loyal to the insights that made Phabricator impactful and build upon.

Enter Graphite—a code review platform purpose-built for fast development.

What is Graphite?

Many developer tools have a singular use or focus. Team members are required to jump between tools to complete the feedback loop. It’s a system of systems that fractures creative flow while complicating organizational alignment and oversight.

Graphite brings all the phases of the software lifecycle into one intuitive developer platform—coding, experimenting, reviewing code, revising iterations, and tracking progress. Graphite integrates within environments engineering teams already use daily, starting with a Git CLI redesigned from the ground up, in addition to integrations with GitHub, Slack, and VS Code.

This unified toolstack eliminates the constant context switching that drains cognitive focus. Developers can execute their entire process from local commit to remote deployment, within one system designed specifically for their needs.

At the same time, the transparency and visibility gained from this consolidation enhances organizational oversight while still allowing a team to maintain autonomy.

Graphite also offers Insights: a birds-eye-view of key code review metrics like total PRs merged, average PRs merged per person, and median review response time. This data-driven approach aims to enhance team productivity by providing transparency into workflow gaps and blockers.

Consolidating metrics into a single dashboard can liberate teams from fragmented toolchains while providing the guardrails necessary for stability. It also facilitates rapid experimentation and peer learning—developers can leverage this feature to explore new ideas and share insights, fostering a collaborative and innovative environment within the team.

Why Graphite?

Before recreating the Phabricator workflow, let's briefly understand key Graphite capabilities that enable translating those practices:

Native GitHub integration

Using a GitHub app, Graphite directly integrates pull requests and branches with your GitHub repository. Changes happen within Git, and the data flows into Graphite, giving you full control and collaboration interfaces, all within the Graphite interface.

Stacked pull requests

While Phabricator organized commits into incremental diffs, Graphite structures changes as groupings of small pull requests—called stacked pull requests—each with a single focused commit. Reviews become more manageable while still tracking interdependencies and allowing incremental integration.

Interactive reviews

Teams can discuss changes within customizable workflows—adding comments, suggestions, and approvals centralized for context. Configurable notifications and a smart inbox streamline human coordination protocols around changes.

Branch tracking

Developers may have branches created using GitHub and don’t have parent branches or aren’t part of a stack. To simplify restacking, Graphite offers branch tracking directly from the command line so you can let Graphite know what the parent branch should be.

The simple gt track command in Graphite handles everything behind the scenes so you can continue working. The next time you restack or submit a stack, this newly tracked PR will be part of the stack.

So, let's see how recreating productive legacy workflows like Phabricator's code review in Graphite's natively integrated experience balances creative freedom and organizational controls even more effectively.

Recreating Phabricator workflows in Graphite

Graphite recreates this tight review and iteration loop at scale. Let’s walk through incrementally enhancing a feature via precise, scoped peer feedback.

Step 1. Start at main branch

Our current main branch contains a basic weather reporting module. It simply fetches and returns the current temperature:

# main.py

import requests

API_KEY = "**********"  

def get_weather():

  url = f"api.openweathermap.org/data/2.5/weather?q=London,uk&appid={API_KEY}"
  
  response = requests.get(url)
  json = response.json()

  temp = json["main"]["temp"]

  return temp 

While functional, we’d like more complete weather data, including atmospheric conditions, precipitation forecasts, humidity readings, and wind speeds. We'll Incrementally augment get_weather() through scoped, iterative peer reviews.

Step 2. Make focused enhancements locally

To begin with, let’s extend the get_weather() to encapsulate additional weather attributes:

def get_weather():

  url = f"api.openweathermap.org/data/2.5/weather?q=London,uk&appid={API_KEY}"
  
  response = requests.get(url)
  json = response.json()

  details = {}
  
  details["temperature"] = json["main"]["temp"]
  details["conditions"] = json["weather"][0]["main"] 
  details["description"] = json["weather"][0]["description"]

  return details

Instead of returning just the temperature, we now return a dictionary with additional attributes. 

The purpose is to maintain existing functionality while allowing modular growth. We’ll save changes locally for isolated reviewing before pushing to main.

Step 3. Initialize branch for review

Now let’s switch to our Graphite command line tool. To push changes with GitHub, you need to first checkout to a branch, add the files, and commit them. With Graphite, it all happens with a single command:

gt create -am "add weather description attributes"

The -am flag automatically adds all the changed files to this commit along with a commit message. It will also automatically create a branch with a name based on your commit message.

Graphite organizes these changes into 00-add_weather_attributes, committed with the message you specify.

To submit the changes, you can create a draft pull request using the below command:

gt submit --draft

This allows peer review without requiring the attention of the final code reviewer.

Step 4. Discuss changes

Graphite makes it easy to discuss changes on specific parts of the PR right from the app. You can have conversation threads within the interface instead of moving to Slack. Here’s a hypothetical conversation between teammates Philip and Lisa about the code modifications and suggested changes.

Philip: Can we include the humidity %? Most weather apps show that.
[Person modifying the code]: Humidity reading makes sense! I will extend to add that metric in the response.
Lisa: This is solid! Wind speed would also be a great context.
[Person modifying the code]: Good callout—will incorporate wind speed as well.

The centralized conversations around isolated changes help the team be on the same page to move forward with the development.

Step 5. Enhance locally per feedback

Let’s revisit our branch and change the weather response model locally to add humidity and wind_speed.

def get_weather():

  // existing attrs

  details["humidity"] = json["main"]["humidity"]
  details["wind_speed"] = json["wind"]["speed"]    

  return details

Thanks to our previous change, adding new attributes becomes simple because we only have to add dictionary items. The rest of the function remains the same.

Step 6. Update pull request

With updates made, we can amend our existing draft pull request:

gt modify
gt submit

The PR synchronizes the latest code for re-review. Philip and Lisa inspect augmented attributes and approve, continuing the tight collaborative cycle.

Note: gt submit defaults to draft PRs in non-interactive mode when it’s your first time submitting the PR.

Step 7. Merge vetted changes upstream

With greenlights from the team, the PR is merged into stable main:

gt merge

The get_weather() function is now available to downstream modules while letting you continue working on additional features without blocking progress due to this one.

Where to go next?

Great cultures keep building—they turn answers into questions, fueling future discoveries and improvements. Phabricator changed how developers work together long before developer productivity became a conversation. It lets them treat early ideas like drafts and get feedback on small changes instead of big finished products.

That environment helped teams feel safe to try creative things.

Hugely successful companies like Facebook, Dropbox, and Pinterest used Phabricator extensively. It earned respect for improving how developers collaborate.

Now that Phabricator is no longer maintained, Graphite helps you retain the principles and workflows while using the latest tech. Integrated with GitHub and VS Code, Graphite prevents constant switching between separate systems. This removes roadblocks that break concentration.

"We've been using Graphite extensively for Next.js the past couple of months. Stacked PRs help land smaller changes faster." — Tim Neutkens, Author of NextJs

The interactive reviews, branch tracking, and automated rules reconnect the fragments so developers can go from writing code to deployment without the blockers.

Experiment with a workflow that boosts development velocity in big tech companies. Try Graphite for free and see how you can positively impact your workflows!