

Ask HN: Single repo vs. repo for each service? - BhavdeepSethi

Recently I’ve been working with having the entire codebase in a single repo way and it’s not really been a good experience. Every time someone modifies code in a separate module, I have to recompile&#x2F;generate sources to fix the compilation errors. Not to mention compiling takes a lot of time as well. Some of the points in favor of the single codebase approach I’ve heard is that you don’t have to worry about versioning. Since everyone has to pull in the same changes, everyone has access to the same thrift sources as well.<p>I’m mostly accustomed to having separate repository for each service. Personally, I think it makes it more manageable. It goes hand in hand with the SOA approach. A bad commit in another service doesn’t affect you.<p>Yet, I’ve seen the single codebase method in bunch of orgs. I believe Google does this as well? I&#x27;m curious to know which one is more common. What are the pros&#x2F;cons that have factored into choosing one over another?
======
w4tson
Devs should never be checking in code that results in a compilation error.
Regardless of whether something needs generating.

Also there’s a difference between an entire companies code in one VCS and a
product with many modules.

I’ve had experience with the latter and can tell you some of the pro’s:

1\. A single version for your product. This helps communications with QA,
clients and managers. And communication is the game we are in whether we like
it or not

2\. Reduced friction in developing features that cut across modules. Lets say
I need to add a column to a database and then expose in the Ui. update the
sql, added the field in a webservice, make the necessary adjustments in the
UI, write the tests all on the same commit.

3\. Increased collaboration. Quite often invisible lines are drawn on
development teams where devs are feel they are unable to modify a module
because they didn’t write it, they don’t understand it or they just feel that
its not a part of their job. With everything in one repo this reduces the
barrier to entry

Its not a free lunch though. Like you mention build times go up For one.

I’m a jvm dev and I find gradle extremely useful in this regard. Features like
Muti project builds and concurrent builds are invaluable

------
tdy721
I like to make lots of repos. You can get a combination of both going with git
when you merge repos together. They don't have to share history. You can setup
remotes that are just paths on your system and make a single repo that
contains branches for each service. You'll end up cloning a single repo a
bunch of times, and fussing with branches instead of repos.

------
Ameo
Ugh - having only worked on personal projects with github up to this point,
the thought of complicated series of repos just to work on multiple aspects of
a project sounds like a huge hassle.

