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.

2 Answers 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.

  • I think your second variant is exactly about our case. And it has a good explanation for the need of it - the separate testing and debugging of our common work. About the first variant - it is interesting, but, I am afraid, too complicated for us yet.
    – Gangnus
    Commented Jan 10, 2018 at 20:36

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).

  • 1. How can you merge more often between creation of pull request and its approval? Not that I am against it, but it seems impossible to organize. Notice, that you are NOT talking about how to do this part of work. 2. I am not talking about branches created for long time for some departments. 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?
    – Gangnus
    Commented Jan 10, 2018 at 11:27
  • You can always merge develop or whatever working branch into your feature branch. This keeps you from going too far off of the mark and make sure your new feature works with everything else. Commented Jan 10, 2018 at 13:25
  • Even between pull request and its approval?
    – Gangnus
    Commented Jan 10, 2018 at 13:59
  • @Gangnus Of course. It's just another commit.
    – mmathis
    Commented Jan 10, 2018 at 14:36
  • 1
    @Gangnus As to your point about multiple developers working on features which touch the same classes, you are probably better off working on one branch rather than 2 (or more), for that exact reason. Or work on one story first and the other in another sprint, after the first is complete. Or write some common interface that you can both use but won't need changing (as much). If you do each work on a separate feature branch, whoever merges into develop last has the bigger job of resolving conflicts ;)
    – mmathis
    Commented Jan 10, 2018 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.