I have found many posts about how to organize work on develop branch and up to release branch. Or even how to work without the develop branch. The trend of the "develop" branch going away, GitFlow branching strategy, but without the develop branch, To branch or not to branch?... But I have problems about how to organize work before the develop branch.
If we create a new branch for every task(ticket), and push it into the common develop branch, it works OK with the smaller projects.
But I have seen larger projects where the more complicated scheme was used - for connected tasks some medium level branches were created, and ticket branches were later pushed not to the developer branch, but to the appropriate medium level branch. And I understand why - If the project is so complicated that more than one person works on the same theme and these developers start to have problems with changes made by others on the developer branch during the time he is waiting for the reactions and approvals of the pull request, and while he works on the appropriate repairs, and has to solve appearing conflicts again and again. I thought that medium level branch could be temporarily locked and thus all participants could push changes into it in turn and that would practically prevent the conflicts. But I have too little experience in large repositories organization and I am not sure at all.
In the description of the GitFlow strategy, http://datasift.github.io/gitflow/IntroducingGitFlow.html, the drawings have this very two-storey scheme. But this part and its practical use is not explained there even a little bit.
The question is: is the scheme of two levels of task branches a necessary and sufficient solution for the problem? And how should it be used to be that solution?
Edit: I am not talking about branches created for long time for some departments. I understand that they are ineffective. Imagine that we both have to do some functionalities that touch the same several classes. Do we need to solve our code conflicts on the develop branch? And if we do it on the common task branch, then we have exactly what I am speaking about: separate local branches and a common thematic branch in the repository.