I have an application that has a back-end database (tables, procedures, database specific dlls) and front-end (application logic and UI) that separate people are working on. I was wondering what's the best way to organize it in my repository (I'm using GIT).

The options I see are:

  • all-in-one repository
  • submodules of main repository
  • two separate repositories
  • other?

Any suggestions are welcome.


I'd go for option 2

submodules of main repository

This keeps the two projects separate (to a degree) and easy to get individually, but clearly shows that they are related.

It shouldn't affect how each group accesses "their" part of the solution.

  • Can you elaborate on the idea of submodules of main repository? – Chris Jan 27 '11 at 14:06
  • @Chris - not really ;) It just seems to represent (or perhaps) how I see the structure in my head/hard drive. I know you can use mappings to put things where you like, but this seems to keep everything "tidy". – ChrisF Jan 27 '11 at 14:10
  • in GIT submodules are like projects within another project. You can commit to the submodule only (it has it's own separate commit log) and the main repository only notices fact of the change in the submodule (not what exactly changed). Great explanation can be found in the free ProGit book - progit.org/book/ch6-6.html – kyrisu Jan 27 '11 at 16:19

two separate repositories

They have nothing to do with each other.

Data lasts for ever and is high-value, an asset to the organization.

Applications come and go. Keep application logic away from database definitions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.