4 ms·

I came from Airbnb (vanilla github) and some friends converted me to a stacked workflow. I think the challenge with vanilla git is that rebasing and re-pushing

I came from Airbnb (vanilla github) and some friends converted me to a stacked workflow. I think the challenge with vanilla git is that rebasing and re-pushing becomes a brutal process if you stack 3+ changes. (At facebook people regularly stack over 10). Beyond recursive rebases, Github offers no support for navigating your stack, merging in a stack of approved PRs together, adjusting merge bases, etc. Most of these practices are just inspired by what Phabricator and a few of the big companies are already doing well :)

treis 5y ago
>(At facebook people regularly stack over 10). Meaning branch 1 depends on branch 2 which depends branch 3... all the way to 10? That just seems crazy to me. What happens if branch 4 changes their implementation and borks everything depending on it?
- shepherdjerred 5y ago
  You have to fix a lot of merge conflicts. I used this workflow at AWS -- code reviews can take some time, you're writing a lot of code, and you want your CRs to be small. If someone leaves a comment on the CR for the first branch you fix the issue and rebase. It's not fun, but this is the only effective way to do it (that I know of).
  - treis 5y ago
    So are the 10 branches mostly yours then? That seems slightly less crazy.
    - shepherdjerred 5y ago
      Yup. I rarely even pushed the branches — they’re local branches
- gorgoiler 5y ago
  Glue code is pretty easily split up into a stack. 90% of what I’ve worked on has been glue code. To ship your change you need to update what’s there already. Tool A needs an integration point. Tool B needs a hook added. Tool C finally joins A to B. Implementing the bits for A and B found two useful refactorings in each codebase. At the end of it all there was also some dead code. That’s 8 commits. The downside is you end up yak shaving a lot.
- howinteresting 5y ago
  Many FB devs don't use branches or maybe use one branch with the entire stack. What you're describing is sometimes a problem but often not really one.
notreallyserio 5y ago
Are you sure about merge bases? I regularly use GH to specify a branch that is part of a different open pull request.

treis 5y ago

>(At facebook people regularly stack over 10). Meaning branch 1 depends on branch 2 which depends branch 3... all the way to 10? That just seems crazy to me. What happens if branch 4 changes their implementation and borks everything depending on it?

shepherdjerred 5y ago
You have to fix a lot of merge conflicts. I used this workflow at AWS -- code reviews can take some time, you're writing a lot of code, and you want your CRs to be small. If someone leaves a comment on the CR for the first branch you fix the issue and rebase. It's not fun, but this is the only effective way to do it (that I know of).
- treis 5y ago
  So are the 10 branches mostly yours then? That seems slightly less crazy.
  - shepherdjerred 5y ago
    Yup. I rarely even pushed the branches — they’re local branches
gorgoiler 5y ago
Glue code is pretty easily split up into a stack. 90% of what I’ve worked on has been glue code. To ship your change you need to update what’s there already. Tool A needs an integration point. Tool B needs a hook added. Tool C finally joins A to B. Implementing the bits for A and B found two useful refactorings in each codebase. At the end of it all there was also some dead code. That’s 8 commits. The downside is you end up yak shaving a lot.
howinteresting 5y ago
Many FB devs don't use branches or maybe use one branch with the entire stack. What you're describing is sometimes a problem but often not really one.

notreallyserio 5y ago

Are you sure about merge bases? I regularly use GH to specify a branch that is part of a different open pull request.