One senior member of my team setup a new git repository for our product we are working on, since we are migrating from SVN to git. Our product consists of different software components that are working more or less completely independent and are also completely different in terms of code. On SVN, these components were all tracked in a single SVN repository with different sub folders for each component and each folder/component was branched separately if needed.

With that background in mind, he setup the git repository with different branches that contain the different components of our product to avoid having the problem, that in git, you cannot branch single folders but only the whole repository at once I assume. So now we just branch the branches.

For me this feels kinda odd since I never saw a repository that was setup this way. I would have created different git repositories for the different components. If everything must be in a single repository I would have used git submodules. But these ideas do not change his opinion.

The problem is, that I cannot really find a strong argument against this approach. As far as I understand, technically this is completely doable and possible with git... The only argument I have is, that SVN is not git and this is not really the git way of doing things. And we will probably run into issues, when we later want to split up the repository into multiple ones.

So are there any strong disadvantages besides the ones I already mentioned?

  • Is it useful? Commented Nov 11, 2020 at 17:12
  • 2
    Seems like that would make it very painful to work on two separate components at once. Or even to just reference one component while working on another.
    – 8bittree
    Commented Nov 11, 2020 at 18:04
  • 1
    Well his idea is that we just clone the repo and checkout the branch. And in another folder clone the repo again but this time checkout another branch. And again this is technically possible so I have no big argument against it...
    – deflox
    Commented Nov 11, 2020 at 21:15
  • There's even a -b option for clone that lets you checkout a specific branch at the same time. Commented Nov 11, 2020 at 22:04
  • @deflox is there any advantage to doing that, instead of using separate repos? Commented Nov 12, 2020 at 14:11

2 Answers 2


First, I just want to say I don't understand why you are migrating if they don't want to use git like git.

I agree with you that it's workable, and it's not even that problematic to split it up later. You would basically just duplicate the monorepo and delete the branches you don't want in each copy.

The main concern I would have is dealing with the gazillion branch names, but that's not any worse than what you've been dealing with in svn. Your pulls are probably also slower, but only marginally. Also, you're likely to have friction with third-party tools like CI that expect a more standard setup, but again, probably nothing you can't work around. It's more difficult to control things like push access per branch than per repo, but that may not be a concern at your company. It's going to be slightly more difficult to onboard new developers.

You really have a people problem more than a technical one. Some people just have to get used to new ideas slowly. I've had more than one occasion where I changed something on practically the same day an intransigent person left the company. Fortunately, it's more likely that as they start to get deeper into the git ecosystem, the git way will become more appealing. Just continue to look for opportunities to (gently) point out situations where separate repos would have been beneficial.

  • The company forced everyone to migrate from SVN to git. Without that policy we would have probably never migrated to git. :) I guess I have to live with this setup, but thanks anyway for your inputs I'll keep them in mind.
    – deflox
    Commented Nov 12, 2020 at 7:50

You should make every “branch” into its own repository.

While it might work like it is now (the technical details are laid out in other answers and comments) it will still introduce a lot of unnecessary complexity. Complexity means that it will be harder to onboard new colleagues, etc.

  • Its somehow a surprise, but nothing extraordinary. But most importantly, nothing blocks him from cloning twice ... Commented Nov 15, 2020 at 23:32

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.