6

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!

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
dagmarPrime
  • 317
  • 3
  • 9
  • Check out the repo, move the files in your local checkout, commit, push. – GolezTrol Mar 18 '19 at 16:51
  • 2
    Possible duplicate of [Is it possible to move/rename files in Git and maintain their history?](https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history) – GolezTrol Mar 18 '19 at 16:53
  • 2
    If you and/or your organization is new to Git, I'd recommend against the monorepo approach. Each independent application should have its own repository. – Daniel Mann Mar 18 '19 at 16:55
  • "docs related to these added projects" you'll need to ensure these "docs" are text files. GIT isn't a document management system, it's for source code. It can't read the docs they'll just be committed as blobs negating any benefit git will bring to this. – Liam Mar 18 '19 at 16:56
  • Thanks, Golez, and others! – dagmarPrime Mar 18 '19 at 16:58
  • @Liam Depends on what format the docs are in. Git itself for example [puts text documentation as part of the main source repo](https://github.com/git/git/tree/master/Documentation). It's an eminently sensible thing to do. – Noufal Ibrahim Mar 19 '19 at 05:38
  • Yes @dagmarPrime that's what I mean't. I've had issues in the past with people checking in word docs then everytime you touch the doc in any way can commit, it add's a new word doc in it's entirety, it a pretty quick way to bloat a GIT repo in a short period of time. – Liam Mar 19 '19 at 09:09

2 Answers2

5

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

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
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.

benhorgen
  • 1,928
  • 1
  • 33
  • 38
  • benhorgen, thanks. My needs are simple so far, so, based on your advice, I guess I'll move the projects up to be full repos. – dagmarPrime Mar 18 '19 at 22:44