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.
2 Answers 2
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– Chris2011年01月27日 14:06:47 +00:00Commented Jan 27, 2011 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– ChrisF2011年01月27日 14:10:15 +00:00Commented Jan 27, 2011 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.htmlkyrisu– kyrisu2011年01月27日 16:19:26 +00:00Commented Jan 27, 2011 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.