In practice when using Phabricator, you (or at least, I) begin to just think of branches more or less as a way of backing things up to a safe location, local incremental development, and cross-developer collaboration -- not as an actual mechanism of reviewing things that will go into the tree.
Really, it's a lot like the mailing list model: you may develop incrementally in whatever way you want, probably between multiple people, but at the final stage you're going to need a clean set of delineated patches to submit for review and someone takes ownership of that part (90% of the time that's you, maybe not you if you're on a multi-person feature). These are more or less two different steps in the development cycle.
This basically happens anyway in my experience at a certain point, even if using GitHub, depending on how your team develops... For example, we recently had a long-lived (~2 month) branch open that accumulated about 300 commits and diverged from our upstream master at $WORK. It implemented a large feature, between many components, and during that time had to be revised in a few ways, due to unforeseen (but minor) things. We didn't just do a direct merge; we assigned individual people subsets of the work, and they were responsible for bringing in the changes in a reliable way. This turned 300 commits into something like 30 or 40. This part of the development is basically the last step, and it took time for us to bite-size the pieces. But then the actual review step -- and submitting the patches -- is a very small part at the end.
A lot of projects like LLVM follow basically the same model (they use Phabricator too but that's more a coincidence, nothing to do with the general flow): the final patch stage is a very separate part from the development stage, all things considered, and posted patches for big features rarely reflect actual development. So, I think putting yourself in this mindset helps. GitHub completely ties the notion of a branch to be both "A thing you use for development" and "The thing that the reviewer finally sees" by way of PR, but clearly this is more a design choice on their part -- rather than a fundamental property of git.
Regarding abstraction, there is a thing about this, which is that you mostly interact through Arcanist to submit patches. This admittedly adds complexity and can confuse people if they think `arc` is just identical to `git`. We had to teach a lot of people to use Arcanist for Haskell.org. This can absolutely be considered a real downside. Admittedly though, Arcanist is an abstraction, and it also works for SVN and Mercurial, so if you have multiple types of repos -- that's arguably very useful! For homogeneous VCS setups, though, I can see how it only seems to add complexity. Realistically, the review stage where you interact with Arcanist is pretty small in the overall development cycle with most changes, but people are still sensitive to it.
---
Honestly I don't think it's a big deal at all, and in fact I find Phabricator's model quite a bit nicer than GitHub's in some incidental ways too, because of it. One nice thing is that you don't have a trillion dead forks of popular repos, search across all patches is unified, stuff like that...
Really, it's a lot like the mailing list model: you may develop incrementally in whatever way you want, probably between multiple people, but at the final stage you're going to need a clean set of delineated patches to submit for review and someone takes ownership of that part (90% of the time that's you, maybe not you if you're on a multi-person feature). These are more or less two different steps in the development cycle.
This basically happens anyway in my experience at a certain point, even if using GitHub, depending on how your team develops... For example, we recently had a long-lived (~2 month) branch open that accumulated about 300 commits and diverged from our upstream master at $WORK. It implemented a large feature, between many components, and during that time had to be revised in a few ways, due to unforeseen (but minor) things. We didn't just do a direct merge; we assigned individual people subsets of the work, and they were responsible for bringing in the changes in a reliable way. This turned 300 commits into something like 30 or 40. This part of the development is basically the last step, and it took time for us to bite-size the pieces. But then the actual review step -- and submitting the patches -- is a very small part at the end.
A lot of projects like LLVM follow basically the same model (they use Phabricator too but that's more a coincidence, nothing to do with the general flow): the final patch stage is a very separate part from the development stage, all things considered, and posted patches for big features rarely reflect actual development. So, I think putting yourself in this mindset helps. GitHub completely ties the notion of a branch to be both "A thing you use for development" and "The thing that the reviewer finally sees" by way of PR, but clearly this is more a design choice on their part -- rather than a fundamental property of git.
Regarding abstraction, there is a thing about this, which is that you mostly interact through Arcanist to submit patches. This admittedly adds complexity and can confuse people if they think `arc` is just identical to `git`. We had to teach a lot of people to use Arcanist for Haskell.org. This can absolutely be considered a real downside. Admittedly though, Arcanist is an abstraction, and it also works for SVN and Mercurial, so if you have multiple types of repos -- that's arguably very useful! For homogeneous VCS setups, though, I can see how it only seems to add complexity. Realistically, the review stage where you interact with Arcanist is pretty small in the overall development cycle with most changes, but people are still sensitive to it.
---
Honestly I don't think it's a big deal at all, and in fact I find Phabricator's model quite a bit nicer than GitHub's in some incidental ways too, because of it. One nice thing is that you don't have a trillion dead forks of popular repos, search across all patches is unified, stuff like that...