How can I most simply reorganize a git repository?

Question

I would like to reorganize a git repo to manage multiple projects. I have one like

my-org
|--cool-repo
   |--file-one
   |--file-two

And I would like to make it like

my-org
|--cool-repo
   |--project-one
      |--file-one
      |--file-two
   |--project-two

I've read some of the git docs, but I am unsure about what commands I should study. I do not need to merge code, or, net, delete anything.

I do not want to break anything.

As my team starts second, third, and later projects, I'd like to organize "subdirectories" or "subprojects" (I am unsure of the term to use) to hold docs related to these added projects.

What should I do, or where can I best resume investigation?

Thanks!

Answer 1

Welcome to Stack Overflow.

If your code it committed and pushed, there's almost nothing you can't do safely so don't worry about making mistakes.

That being said, in your specific case, you don't need to do do much. Simply create the new directory project-one using mkdir project-one. Move your file-one and file-two into it using git mv file-one file-two project-one and then commit the new changes using git commit (the git mv command will automatically stage the renames).

Answer 2

A couple notes about your situation. Unlike SVN and other traditional source control management systems, Git is primarily designed to host 1 project per repo. That is by no means a hard rule, there are ways to host source code from more than 1 project in a single Git repo. But here are two reasons to consider using a Git subtree or submodule instead.

1.) Because Git is a distributed source control management system, repositories can grow in size much more rapidly. This can make cloning a repo a large pain.

2.) Because a Git commit is a commit to the entire repo not just a sub-folder, a merge into the master (or equivalent) branch can get complex for newbies. And the history of a branch can be more challenging to understand what really changed in a set of commits.

It can be helpful to give a full-stack dev team a single repo to clone in order to work the whole solution. In your case I might consider a "host" repo that contains subtrees or submodules to the Git repos containing different components of a full-stack solution. This would enable a developer to do a single clone and still get the full source code.

I suggest using a submodule if the components are tightly coupled and change often in sync. Use a subtree is the components are integrated less frequently and/or on a defined release schedule.