Git Repository Setup

Question

I am moving my companys source control from TFS to GIT. We have TFS currently defined as.

• Project Collection /
  • / Client A
    • / Product A
    • / Product B
    • / Product C
  • / Client B
    • / Product D
    • / Product E
    • / Product F

What is the best way to do this in Git? I have thought about the following:

• Repository (Client A)
  • Branch (Product A)
  • Branch (Product B)
  • Branch (Product C)
• Repository (Client B)
  • Branch (Product D)
  • Branch (Product E)
  • Branch (Product F)

What do you think is the best approach as the design is slightly different?

• Andy: Are the products distinct? If yes, why not create one git-repo per product?

Answer 1

You should create a new repo for each independent project. Why?

• Someone working on project D does not have to download all the history for E and F.
• Git repos are cheap to initialize, so you can use as many as you like.
• It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly look up something, you'd have to stash your uncommitted changes, then check out the the other branch (which would rewrite the complete directory structure, expensive for large projects), then check out the original branch again and apply your stashed changes. It's not generally possible to view the projects side-by-side without cloning the repo multiple times.
• The history will be a mess. When using Git, one will sometimes work on multiple feature branches that get merged back in after a while. But when having a project per (main) branch, you'd have multiple parallel but absolutely unconnected branches. They share nothing, so why should they share the repo?

If a project depends on another project, you can use git submodules to connect the repos without having to put everything in a single repo.

Answer 2

At our company, we develop all source code from one large repository with individual folders for each client/product. Although clients each receive their own individualized software package, all our products have our expertise in common and we re-use much of our code. This re-use happens through shared libraries. Having all client projects in the same repository allows to fulfill all the necessary library dependencies.

Even if at this point in time all your software products are distinct and non-overlapping, code re-use and shared libraries may come in the future. This extension will be very easy in a single repository, but more intricate with multiple.