Normally, when I start up a new application, I’d create a new git repository for it. That’s well accepted and plays nice with Github when I want to share my code.
At work, I’m working in a service oriented architecture. One very common pattern is to add some code to two different applications at the same time – perhaps adding a model with a RESTful interface to one and a web frontend for managing it on another. Using separate git repositories has some warts in this case.
Here are what I see as the downsides of doing separate repositories:
- I have to commit twice
- I can’t correllate related commits very well
- No single place to go back and trace history – I’d love to be able to bring up all my commits for the day in a single place
- Forgetting to pull one repo or another is a gotcha
On the other hand, I’ve used perforce a lot and its one giant repository model has lots of warts too. Perforce has features designed to let help you with those, git doesn’t.
Has anyone else run into this situation? How did you handle it? What worked well, and what didn’t?
If your different repo are part of the same global application, you can bring them together as submodules within a main project.
From there you can:
commit the submodule only once in project P1 (if a submodule need to be reused in another project P2, you go within that other project P2, in the subdirectory referencing said submodule you just committed in P1, checkout that commit, go back up one level and commit that other project P2, since P2 has to reference the same commit that P1)
all related commits are referenced by the main project
a “super-main” project can reference all your submodules out there, in order for you to have that “single place to go back and trace history”
you only need to pull the main project, and that will pull the right submodules references.