I am new to Git and am learning as much as I can about it.

The latest thing I would like to know is how to approach this problem: I have a single folder (R) that I initially set up as a Git repository.

Since setting R up, it now contains several projects and it is now the case that I have several branches, each reflecting a different project and I don't like it because it feels untidy and disorganised.

As such, I am thinking that the best way to approach the problem might be to create a new repository for each project. (Note that each project is a sub-directory of R.)

However, I know that creating a new repository means starting afresh (i.e. no branches or previous commits). Second - I'm sure the answer is yes - but I wonder if I can copy across a branch from R where I used to track changes previously so that I can continue with the new project as a repository as opposed to being a sub-directory of another repository.

So I have two questions:

  1. Is it a good idea to split each project out into its own repository? (If so, will this affect the overall structure of R? The idea is that I stop using R as a repository and instead use R\Project1 and R\Project2, etc, as separate repositories.)
  2. Is there a way to copy a branch from R into the new repository?

Note: I am the sole developer/user of these files at present - no others are involved.

  • I would be very surprised if it weren't possible. If you think each individual project might be useful in other situations, then absolutely don't hesitate to put it in its own repository.
    – Neil
    Commented Jul 24, 2018 at 12:46
  • It's getting to the point now where I have five branches and it's becoming difficult to easily keep track of which project is which. I predict that over the next 12 months that number will increase to around 20, maybe even 25. I think if I split each project out into their repositories, then that will make things significantly easier to manage. The only thing really holding me back is whether or not I can also move the corresponding branch(es) across from R to the new repositories. Commented Jul 24, 2018 at 12:48
  • You can simply create one empty remote and one regular clone per new sub-repo, rewrite with git filter-branch to discard the subdirectories and/or branches not relevant for that clone, and then push to the new remote.
    – Useless
    Commented Jul 24, 2018 at 13:39
  • @MusTheDataGuy I have five branches and it's becoming difficult to easily keep track of which project is which This sounds like your process could be improved in some way. In my team we have dozens upon dozens of branches in a repo with multiple projects, and there is hardy ever any confusion about which is which. Are the branches focused on one feature/fix, and do they have descriptive names? If you're developing multiple things at once, do you use an issue tracking system?
    – abl
    Commented Apr 6, 2023 at 19:50

4 Answers 4


1> NO - that is not GENERALLY a good idea (but maybe a good idea in some cases).

2> You can always clone a repository, and delete the unwanted branches.

A good way to get a feel for appropriate git project layouts is to spend a few hours randomly wandering around github, and looking what other people do.

Generally, the guiding light on what makes sense to be in a single repository has very little todo with code organization - but lifetime of evolution. The one thing you want to avoid, is having to ever make changes that CROSS repository boundaries (can happen, but choose a structure where this is extremely unlikely).

And choose a structure where transitioning from alpha test, to beta, to release all will happen at the same time.

You can always COMPOSE repositories into larger chunks with sub-modules. But breaking them into smaller parts is harder (because of other teams/team member dependencies on the existing repository structure).


Answering question 1:

If this projects don't depend on each other just split them into separate repositories.

If they do depend on each other: split them and set them up using submodules. Or - if you have composing tools for your platform - use them.


1) If each project is a dependency of a larger project, I would not split them into separate repositories.

If you split a dependency into another repo, it will eventually get versioned, and the version used between dependant services will eventually diverge causing breaking changes.

You can take advantage of them being logically split into different folders for the majority of use cases. e.g. deploying them and scaling each "project" as a different service.

I feel that you should only split into multiple git repo's if you want to give different people access to different parts of the code, or if you wanted something like configuration in a separate repo, it really depends on your situation.

However, you say you are learning, the best thing to do is try it.

2) To split them into new repos, just move the folders out and init the repo. Then create the repo on github, and add the remote for each of these repositories. i.e.

mv ../old-repo/new-repo . 
cd new-repo 
git init 
git remote add origin [email protected]:User/UserRepo.git
git add -A
git commit -m "init"
git push origin master

Not a GIT expert, so this is a suggestion for someone else to jump on. Can the OP not create multiple iterations (branches?) of the repo, then turn those into "masters" (or whatever it's called), (and rename them and and boot the unnecessary stuff), so each repo would preserve all of the changes up until now, but be different in what they have deleted?

  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Apr 7, 2023 at 22:58

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.