Stacked Pull Requests | GitKon 2022 | Tomas Reimers, Graphite
HTML-код
- Опубликовано: 17 окт 2022
- Stacking PRs: How to be a 10x Engineer
See the benefits of using stacked pull requests in your workflow to improve the code review process and get your PRs approved to merge into the main project.
“Stacking” is a workflow that involves developers branching off of previous feature branches rather than a trunk. The advantage of this approach is that you can avoid blockers while building new, dependent features, and you can write smaller pull requests, leading to faster review cycles and fewer merge conflicts. However, despite the benefits of stacking, many people avoid it because native Git lacks built-in support for this strategy. Tomas talks about why developers should consider stacking, how to make it easier, and tools that enable you to get started today.
Tomas Reimers is a co-founder of Graphite, a company re-building code review for fast-moving teams while taking inspiration from the internal tooling at Google, Facebook, Microsoft, and others. Prior to starting Graphite, Tomas was a software engineer at Facebook working on mobile product infrastructure and servicing over 1000 developers across the company who were building products such as search, news feed, integrity, shopping, etc. Tomas is passionate about serving developers and finding ways to accelerate the speed of software development.
#stackedpullrequests #git #gitpullrequest #gitkon #gitkraken #codereview 
Наука
Having worked with stacked PRs at meta for 3 years, then moving to a company that doesnt have it, my productivity seemed to halt. Stacked PRs is one of those things where you dont realize just how incredibly powerful it is until you've used it and its taken away. Good job guys!
This is such a simple solution to a problem I've had for a long time. Thanks for the clear and well-prepared video!
we got 99 issues and my branch ain't one
What is actually the difference between this and just managing feature branches?
they seem identical. maybe hg doesn't do feature branches well? but ya. that's just feature branches by another name.
You merge feature branches when the feature is complete, which can involve a large amount of changes and take a long time. That would be against both Continuous Integration and Continuous Deployment principles.
By contrast, in this workflow, you review and merge every commit separately and sequentially, while avoiding the need to stop working while waiting for the review, or context switching to another task, both of which can severely diminish your performance.
IMO, to complete the picture, a comparison to trunk-based development is missing in this video. I agree that asking to review massive PRs is very expensive for everyone. However, I'd argue that big PRs are symptoms of a bigger, often organisational problem. If I understand correctly, you are proposing a tool that runs a series of rebases automatically. But I think the main problem is the fact that we need to start a PR in the first place. So, I'd say there are two approaches to working on a single codebase as a team: trunk-based and some sort of branching strategy. I think you need to expand on this one.
As a side note, the bigger issue is that many engineers don't understand what rebase does, and why merging 'main' into a 'branch' is . So, I'd say start there first.
i don't think you even necessarily need (nontrivial) rebasing for this workflow unless someone else gets a PR merged in between your stacked PRs. from a git-perspective you can also include a bunch of merge commits and skip rebases entirely. it doesn't really matter from a workflow-perspective
anyways, the issue is still that you're still blocked on reviews for merging and blocked on merging for continuing work if you're not willing to stack PRs, regardless of if you're using trunk-based development or not. this is a part of the reason why people make large PRs, because they don't want to be blocked frequently having to wait for review and CI before being able to continue working
or are you proposing not doing review at all? the info i can find on trunk-based development still uses short-lived feature-branches with PRs unless you're a very small team. not everyone can rely solely on pair-coding for review, you need some outlet for asynchronicity
Great idea but this is already possible with rebasing. Rebasing may incur some headaches but most of that can be avoided with good communication amongst teammates.
All this complexity because you needed someone to review your PR but the team is too busy, possibly due to high work in progress (WIP)
This is exactly the opposite of lean, adding more PRs will increase your WIP that inevitable will make all PRs slower and those you need to review too
It may feel like your are going faster but I encourage you compare your deployment frequency if you don't stack.
An alternative solution would be for the team to reduce your collective WIP and leave slack capacity for timely reviews
"Stacking lets you make many small PRs easily, and without having to wait for review." I don't need a tool to do that right? I can just make small PRs.
No, then you run into the problem presented at the top of this talk. Splitting your PRs into smaller pieces without stacking them means you either have to wait for parts to be reviewed and merged into main before working on the next piece, or doing some git reset thing and dealing with merge conflicts later.
@@cool_scatter feature branches... exist...
@@Jalae You still... have to deal... with conflicts... when merging... feature branches... out of order... especially for large teams...
What is this terribly inefficient format of a presentation? Just get to it...