26 ms·

Usually when feature-branch-1 is still under review and feature 2 relies on feature 1, I just open a PR from feature-branch-2 onto feature-branch-1 to get the r

Usually when feature-branch-1 is still under review and feature 2 relies on feature 1, I just open a PR from feature-branch-2 onto feature-branch-1 to get the review process started, knowing that feature-branch-1 might still change which I can deal with by rebasing.

milkytron 5y ago
Yeah this shouldn't be an issue when following standard git branching practices. It's kinda the point
fosterfriends 5y ago
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.
Denvercoder9 5y ago
One problem with GitHub is that you can't do this with branches from a fork.
- hobofan 5y ago
  Can you be more specific what you think can't be done? I just tried it, and I can without problem open a PR from a fork against an arbitrary branch of an arbitrary fork (or main repository).
  - Denvercoder9 5y ago
    You can't open a PR in the parent repository against a branch in the fork. You can create that PR inside the forked repository, but that doesn't allow the maintainers of the parent repository to do anything with it. So if you've got two stacked branch in a fork, you can't open two PRs for them in the manner GP described.
- pas 5y ago
  but if everyone works at the same company they can create the branches in the same repo

milkytron 5y ago

Yeah this shouldn't be an issue when following standard git branching practices. It's kinda the point

fosterfriends 5y ago

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.

Denvercoder9 5y ago

One problem with GitHub is that you can't do this with branches from a fork.

hobofan 5y ago
Can you be more specific what you think can't be done? I just tried it, and I can without problem open a PR from a fork against an arbitrary branch of an arbitrary fork (or main repository).
- Denvercoder9 5y ago
  You can't open a PR in the parent repository against a branch in the fork. You can create that PR inside the forked repository, but that doesn't allow the maintainers of the parent repository to do anything with it. So if you've got two stacked branch in a fork, you can't open two PRs for them in the manner GP described.
pas 5y ago
but if everyone works at the same company they can create the branches in the same repo