Question

We are doing development for automation code.

Our code automates the company’s products and is synced to a particular product version.

Currently, we have 1 big Git repository with multiple branches in it – v1.0, v1.1, v2.0 (automation for version 1.0 goes in v1.0 branch, and so on).

What are the advantages and disadvantages of having these in a single repository with branches vs. keeping each version code in a separate repository ?

Both solutions can work, the answer i’m looking for is a list of pros/cons for either approach.

I know that many teams are using branches to isolate temporary stages in development, such as doing a bug fixes or a new feature, merging back the work into the main development branch in the end.

Other modes of work i know are having different branches for development, release, etc, to separate “cleaner” revisions of the code from dirty ones that are constantly being worked on.

None of these sound similar to what we are currently doing though.

*Note that some modifications in a particular version we make are relevant for all product versions, while some are not.

Answer 1

Multiple branches

Pros:

• only one repo to manage (your automate points to one remote)
• comparison (diff) between branches possible directly from that one repo
• you can pull any of those branches from that one repo to any other downstream repos which might need it

Cons:

• branch cluttering (you need to manage/delete the sum of the branches)
• tags are for all the repo (not just for “some products”

Multiple repos

Pros

• you can pull from the main repo only what you need and work from there
• you can clean easily old “branches” (just delete that specific repo)

Cons

• repo duplication (takes more space)
• repo management (you need to point to the right remote(s))

---

I would argue the single repo approach is a simpler and more classic approach.
That said, if you have many versions (which need to be cleaned up regularly), isolating those transient versions in their own repo can work too.