Our second-ever launch week was exhilarating to say the least. We've been overwhelmed by the community response and customer interest in these new features.
This is a quick overview of everything we announced last week, with a linked deep dive for each announcement.
Interested in trying these new features? Sign up for beta access and we'll be in touch!
Multiple engineers can now seamlessly collaborate on the same stack of PRs
All developers using Graphite can now confidently work together with their teammates on a shared stack of PRs - simply gt get, gt create, and gt submit to fetch and share changes. Behind the scenes, Graphite automatically resolves and reconciles the complex Git states needed to make easy collaboration possible.
👉 To get started, update your CLI to v1.3.4+. Read more about the change in the blog post.
Graphite will now automatically rebase your partially-merged stacks
Graphite now automatically rebases partially merged stacks for you - so you never have to remember to run gt sync && gt submit to rebase the upstack PRs. Your teammates will always see the correct diffs on Graphite or GitHub, and you won’t have to worry about the wrong reviewers being assigned to your PR.
Automatic rebasing also works seamlessly with your local branches - just run gt sync as you’d normally do before re-starting development and Graphite will pull in the rebased branches from remote and apply the changes locally.
👉 We're gradually rolling out automatic rebasing of partially merged stacks (learn more).
Introducing Graphite merge rules: Better code ownership & more flexible branch protections
Graphite merge rules is the next generation of branch protection rules and codeowners, built for fast-moving development teams. With it:
Individual teams can customize & enforce their own codeowners and PR mergeability requirements, while still remaining compliant with their company’s policies.
Define merge requirements for specific directories, code authors, branches, PR sizes, types of changes, on-call engineers, and anything else — instead of setting overly-broad or overly-strict branch protection requirements.
Let PR authors override specific rules while still enforcing a high quality bar. For example, disallow merging large PRs by default that aren’t code mods or reverts.
👉 Read the rest of the post to learn more about Graphite merge rules
Cheaper CI & faster merging with batching
Batching is a workflow where the merge queue groups several to-be-merged PRs together into a temporary combined PR, runs CI on it, and then merges all of them together if everything passes. If something goes wrong, the merge queue can bisect the batch and help you find the breaking change.
Batching is an effective strategy for both handling a higher volume of PRs and reducing CI spend.
👉 Learn more about batch merging in the blog post
Reduce CI costs for Buildkite and GitHub Actions
We’re excited to introduce first-class integrations with Buildkite and GitHub Actions that empower you optimize your CI pipelines for stacking, so your releases stay reliable while your costs stay in control.