1

I am new to Git, and am trying to figure out how use a git repository when a project's files are spread across different drives.

For example: The project requires html files on one drive. The CSS and JavaScript files are stored on a different drive. I don't have the option to keep them together.

Is there a good way to store these files together in the same Git repository, and only grab the specific files you need in each drive? It makes sense to store the files together in the repository, as they are all for the same project.

The only solution I can come up with is to make multiple repositories for each project, one for the files on each drive.

4
  • 1
    Where does my git question go?
    – gnat
    Commented Oct 21, 2016 at 15:17
  • 3
    My first thought would be to put them together in the repository but include a build script that pushes the files to their respective drives. That said, the setup in general seems a little wonky. I would try to find a way to at least develop off of one drive even if the final deployment looks a little different.
    – Michael
    Commented Oct 21, 2016 at 15:27
  • 2
    @gnat This appears to be a git workflow and configuration management question, which makes it on-topic here. Organizing repositories and structuring files for appropriate control belongs here.
    – Thomas Owens ♦
    Commented Oct 21, 2016 at 15:27
  • I bet there's a reason if css and js are in a different place than html. According to why you have this uncommon resources placement you should make that decision about git. In my opinion it makes sense to have one repository for each drive, so one repo for css and js and another repo for html that goes independently. Merges and conflicts are already complex maybe there's no need to increase complexity by adding multiple drives. But really it depends on your development process...
    – JoulinRouge
    Commented Oct 21, 2016 at 15:51

1 Answer 1

Reset to default
7

I would stay away from using the execution/deployment directory as the primary factor for deciding how many repositories to create. That is a build and deployment question. You could change that architecture without having to make significant code changes and then your repository organization doesn't make sense.

I would create repositories based on the composition of the components in your application/website/service/*. For example, one for front end/UI, one for services/middle tier, one for database and one for library or common code. These also map more closely to deployable units which I have found to be a nice organization.

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.