2

I'm new to git, and I've been tasked with moving an existing project into git. The problem I have is that it's really 2 projects. Let's call the project "One". One is actually both a reporting site, as well as a group of code templates that are used by individual projects (which enables the reporting site to run reports standard between projects). We want to run the reporting site on our dev & reporting servers, and have the code templates on our dev and production servers. So, sometimes both repositories will be needed, and othertimes only 1. One was written with a code structure like this:

/one (generic main dir, no files, only sub-dirs) /onesource (PHP source code for the reporting site) /onerept (reports run by the reporting site) /onelib (templates) /oneinc (include files used by templates) /oneadmn (files used by both)

So, the reporting site repository will want to contain the onesource and onerept sub-dirs, while the templates repository will want to contain the onelib and oneinc directories. I can make the oneadmn dir into a shared mount between servers if need be. Everything is currently set up as a shared mount, but this is bad for multiple reasons.

How do I set this up in git?

Improve this question

2 Answers 2

Reset to default
5

The standard rule is: Everything that is developed, versioned and released together goes into one repository. Consequently, parts of a project with independent version numbers go into their own repo.

The reason is that branches and tags in git are always repository-wide (unlike in Subversion).

By that rule, I'd say everything should go into one big repo.

As to what data is required on which server: You could either have some deployment process that copies only what is needed, or you just check out everything. From your question it does not look like it would hurt to have everything available.

At any rate, if you need a certain directory structure on a certain server, that's a deployment issue. The repository should be arranged for development, not for deployment. Deployment comes later, and has its own set of tools.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

4

Does it actually harm to use the same git repository in both environments? Unless there are some non-technical policy reasons why you want different repositories, there's no harm in having a single repository for everything, and using only what you need in each context. This is the simplest thing to do, and causes the least amount of confusion.

Other options are:

1) Create a separate branch for each environment. Use the same git repository, but different branches for each environment.

2) Create multiple git repositories. One git repository for your shared parts, and one or more other git repositories for the separate parts; or perhaps a single repository for the separate parts, kept as different branches.

This is one thing that git does not really handle very well - having a hierarchy of separate repositories glued together. I used the second approach in one of my projects, which consists of several top level source repositories, and some shared modules. Each top level project is a separate branch in the original project. To work on a top level project, I clone the main repository into a new work directory, then clone the shared module repository in the "libs" subdirectory in the work directory.

This is not really an ideal scenario, but it generally works. Just have to be a little bit organized and keep in mind that the "libs" subdirectory is a separate git repository.

In your case, you would move "onelib" and "oneinc" into a second git repository, and clone it into a separate subdirectory, called "shared", I suppose. You will then need to change the rest of your code to reference "shared/onelib" and "shared/oneinc", in this case.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.