0

I have a personal project that I want to version control, but I'm not sure how I should use git to manage it. Below is an example of the folder structure:

project
project/public/plugin1
project/public/plugin2
project/lib/plugin1
project/lib/plugin2

I was going to create individual repositories for each plugin or module, but it seems a bit tricky because not all files of the plugin are grouped together under the same folder. So I'd need to track these directories as plugin1:

project/public/plugin1
project/lib/plugin1

And similarly for plugin2:

project/public/plugin2
project/lib/plugin2

In the public folder is files such as css and js, so you could say the more important files are the ones in lib. Should I set the repository in that folder and somehow try to add the external public folder? But of course git won't let me do that. I've already tried this from another question as well:

git --work-tree=/ add /project/public/plugin1

I still get an error saying it's outside the repository.

As this is just a personal project I have no need to access or do anything remote, which hopefully removes some complications. Any ideas on the correct way to set this up? Thanks.

user1699176
  • 813
  • 1
  • 6
  • 5
  • Why do you want to separate them? I guess you could do that with subtrees, but it might complicate things quite a bit. Do you think this is really necessary? – Renato Zannon Oct 05 '12 at 23:19
  • @Renato Zannon I need to separate them because each plugin would be a separate release. So maybe plugin1 would be at version 1.5 and plugin2 would be at version 2.1, etc. – user1699176 Oct 05 '12 at 23:36
  • I think this should be handled by the language/framework that you are using, not git. What is the technology you are developing on? – Renato Zannon Oct 05 '12 at 23:38
  • @Renato Zannon This is a php/mysql project. I'm not able to move around the folders though. If all plugin files resided in the same folder it would indeed be much easier to use with git then. So is there no way to individually track these plugins? – user1699176 Oct 06 '12 at 00:07
  • Personally, I'd start with the simplest thing that works, that is, make it one repo, then split it when there was a specific need to. – Don Branson Oct 06 '12 at 00:53
  • @Don Branson Is my situation not a specific need for separate repositories? For example if I have a single repository, how do I version track each plugin? If I set the repository to say version 1.5, then every plugin would be version 1.5, when it should just be that specific plugin. Or am I missing something of how this can be done with one repository? – user1699176 Oct 06 '12 at 02:46
  • @user1699176 What do you mean by "version 1.5"? A "v1.5" tag? Another thing: Will you ever need to split this repository in multiple repositories? – Renato Zannon Oct 06 '12 at 02:59
  • @Renato Zannon Each of the plugins has it's own version. It might start at version 1.0 alpha, then beta, etc, but that would only be for plugin1. Maybe plugin2 is already at version 1.2.1 or whatever. And depending on the pace of development and need for bug fixes or what not, the plugins will never be at the same version. That's why I'm not sure how to do this with just one repository. – user1699176 Oct 06 '12 at 03:09
  • @user1699176 if your only issue is the version numbers, then you are fine. Git doesn't really have the notion of versions, the farthest you get is the tags. In your case, you can use tags like `plugin1-v1.0` instead of just `v1.0`. – Renato Zannon Oct 06 '12 at 03:13
  • @Renato Zannon Hmm, so I would also set up branches prefixed with the plugin name as well? Some problems I could see with this are when it comes to merging. Wouldn't I have a ton of merge conflicts each time? – user1699176 Oct 06 '12 at 03:26
  • @user1699176 You certainly could do that, but it wouldn't be required. Just maintain everything in the main line, and mark with a tag when you want to make a 'release' of a plugin. You won't get the cleanliness of dedicated repository, but your history will be maintained. Then you can use something like [git-subtree](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt) to split the repository later on. – Renato Zannon Oct 06 '12 at 03:36
  • @Renato Zannon I think I would need to prefix the branches then, because not every release would be completed before a release of another plugin is completed. Imagine plugin1 at 1.1 and plugin2 at 1.5. Now I start working on 1.2 of plugin1, but it's not ready yet and suddenly I need apply bug fix 1.5.1 for plugin2. As for the merge conflicts I came across this and I think this might work so I don't need to merge unrelated files of other plugins: http://stackoverflow.com/a/1355990 I'll have to try it out. Will also read up on git subtree that you posted later on, thanks. – user1699176 Oct 06 '12 at 03:51
  • @user1699176 - When I'm thinking of a specific needs, what I have in mind is that the separation is currently required so that I can release the plugins separately from the main project, say, for example, if I have more than one application that needs the same plugin. That would be a business need that's driving the need for a reusable plugin, which in turn drives the need for separate repositories. – Don Branson Oct 06 '12 at 12:31
  • @user1699176 - In contrast, if there's only one application, and I'm using separate plugins to gain Separation of Concerns, then I would leave them in one project and one repo for now. Later, when a second application comes along that needs the functionality that's in one of the plugins, I might pull the plugin into its own repo at that point in time. – Don Branson Oct 06 '12 at 12:34
  • @user1699176 - Another example of a specific need would be if holding the application in one project causes long build times. Separating the functionality into separate plugins is a mechanism to deal with that, and that might drive the separation into multiple repos. – Don Branson Oct 06 '12 at 12:36
  • @Don Branson Yea I decided to go with just a single repository now. I will try just prefixing my branches and tags with the plugin name and hopefully I won't have any issues. – user1699176 Oct 06 '12 at 18:20

1 Answers1

0

Looks like an older question but, for anyone looking at this, what you want to do is use git submodules.

  1. Create repos for your main project, and any modules (libraries, plugins, modules, etc.)

  2. Your structure may vary but you want to create submodules in the main repository that reference other repositories that contain your plugins, etc.

    # git submodule add git://path-to-your-repo.git modulename

  3. Note that you pull content into the main repo and it is attached to that revision of the main repo which allows you to only pull specific versions of the submodule when it is compatible with the main project. The following pulls the submodule project into the main project.

    # git submodule update modulename

That's just a high level overview. Try reading http://www.git-scm.com/book/en/Git-Tools-Submodules for more detail.

Jered Cuenco
  • 16
  • 1
  • 2