Git Submodules vs. Google’s Repo Tool

Last updated on Sep 26,2020 13.2K Views

Anton Weiss
Anton Weiss is a DevOps Enablement Expert with hands-on experience throughout the... Anton Weiss is a DevOps Enablement Expert with hands-on experience throughout the software development life cycle. At Otomato, he consults for DevOps, architecture and...

I was recently asked by a customer to outline the pros and cons of using git submodules vs. google repo tool to manage multi­-repository integrations in git.

There are a lot of articles on the internet bashing each of the tools, but in our opinion ­ most of it comes from misunderstanding the tool’s design or trying to apply it in an unappropriate context.

This post summarizes the general rules of thumb we at Otomato follow when choosing a solution for this admittedly nontrivial situation.

First of all – whenever possible -­ we recommend integrating your components on binary package level rather than compiling everything from source each time. I.e. : packaging components to jars, npms, eggs, rpms or docker images, uploading to a binary repo and pulling in as versioned dependencies during the build.

Still -­ sometimes this is not an optimal solution, especially if you do a lot of feature branch development (which in itself is an anti­pattern in classical Continuous Delivery approach – see here for example).

For these cases we stick to the following guidelines.

Git Submodules:


1. An integrated solution, part of git since v1.5

2. Deterministic relationship definition (parent project always points to a specific commit in submodule)

3. Integration points are recorded in parent repo.

4. Easy to recreate historical configurations.

5. Total separation of lifecycles between the parent and the submodules.

6. Supported by jenkins git plugin.


1. Management overhead. (Need separate clones to introduce changes in submodules)

2. Developers get confused if they don’t understand the inner mechanics.

3. Need for additional commands (‘clone ­­recursive’ and ‘submodule update’)

4. External tools support is not perfect (bitbucket, sourcetree, ide plugins) ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

Google Repo:


1. Tracking synchronized development effort is easier.

2. Gerrit integration (?)

3. A separate jenkins plugin.


1. An external obscure mechanism

2. Requires an extra repository for management.

3. Non­deterministic relationship definition (each repo version can be defined as a floating head)

4. Hard to reconstruct old versions.

5. No support in bitbucket or gui tools.

In general : Whenever we want to integrate separate decoupled components with distinct lifecycles ­ I recommend submodules over repo, but their implementation must come with proper education regarding the special workflow they require. In the long run it pays off ­ as integration points can be managed in deterministic manner and with knowledge comes the certainty in the tool.

If you find your components are too tightly coupled or you you’re in need of continuous intensive development occurring concurrently in multiple repos you should probably use git subtrees or just spare yourself the headache and drop everything into one big monorepo. (This depends, of course, on how big your codebase is.)

To read more about git subtree ­- see here.

The important thing to understand is that software integration is never totally painless and there is no perfect cure for the pain. Choose the solution that makes your life easier and assume the responsibilty of learning the accompanying workflow. As they say : “it’s not the tool ­ it’s how you use it.”

I’ll be happy to hear what you think, as this is a controversial issue with many different opinions flying around on the internet.

Keep delivering!

This blog first appeared on

Edureka has a specially curated course on Git and Github, co-created by industry experts.

Related Post:

‘Git’ting Ahead: Hacking Git and GitHub

Upcoming Batches For DevOps Certification Training Course
Course NameDate
DevOps Certification Training Course

Class Starts on 28th November,2022

28th November

MON-FRI (Weekday Batch)
View Details
DevOps Certification Training Course

Class Starts on 17th December,2022

17th December

SAT&SUN (Weekend Batch)
View Details
DevOps Certification Training Course

Class Starts on 26th December,2022

26th December

MON-FRI (Weekday Batch)
View Details
  • SacTiw says:

    Nice post!!!
    One question: You haven’t stated when to prefer using repo tool?

  • Philip Stefanov says:

    4. Hard to reconstruct old versions.
    repo tool can create snapshot manifest

    • EdurekaSupport says:

      Hey Philip, thanks for checking out our blog. In order to keep a backup of the project, you can create a repo manifest snapshot for the project. To explain this further:
      The purpose of Git is to manage a project, or a set of files, as they change over time. Git stores this information in a data structure called a repository.
      Repo is a repository management tool built on top of Git.It’s first purpose is to downloads files from multiple git repositories into your local working directory.
      A repo manifest describes the structure of a repo client; that is the directories that are visible and where they should be obtained from the git
      Manifests are inherently version controlled, since they are kept within a Git repository. Updates to manifests are automatically obtained by clients during `repo sync`.
      Hope this helps. Cheers!

Join the discussion

Browse Categories

webinar_success Thank you for registering Join Edureka Meetup community for 100+ Free Webinars each month JOIN MEETUP GROUP

Subscribe to our Newsletter, and get personalized recommendations.

image not found!
image not found!

Git Submodules vs. Google’s Repo Tool