The two-storey branching scheme **before** the develop branch

Question

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.

Answer 1

If you get many conflicts, you need to merge more often, not less.

The idea of gitflow - as I understand it - is not to protect the developers on the feature branch from changes to develop, but to keep unfinished features out of develop so that develop only contains features that are ready for release.

For features that take longer, you should merge develop into your feature branch regularly. If you have a lot of those active feature branches, you might have to cross-merge them as well. This usually shouldn't cause problems, because merging works quite well in git.

Now I suppose you could add an additional layer to keep unfinished sub-features out of the feature branch. Just note that this may quite significantly increase the amount of cross-merging that is necessary. Perhaps it's better to find a way to avoid very long lived feature branches.

As you noted yourself, many projects don't use feature branches at all (=> continuous integration/deployment).

Answer 2

With distributed version control, the branching model is just the global public interface to the central repo. How code gets into the feature branches is out of the model's scope, and is completely up to individual needs at any given time. It can involve a single branch or many.

A relatively common pattern for me is I create a feature branch for myself, then a pair programmer frees up so I give him direct push permission to that branch, then other people need my in-progress changes for their contributions to the feature, so they fork my branch and submit pull requests to my branch. They might in turn have developers submitting pull requests into their branch, but from my point of view I don't care. When the feature is complete, I merge master into my branch, then submit one larger pull request, squashed or rebased if desired.

Another relatively common pattern is I will create a feature branch, and another developer will independently create their own related feature branch. They are standalone branches, so they could be merged into master independently, but we want to make sure our changes work together, so we locally merge each others' branches first, do some local testing, then back out the merges before we submit pull requests to master.

You don't need to formalize communication at that level, or do the same thing every time, just adapt as the needs of the moment dictate.