Benefits of using git branches vs. multiple repositories

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.

tags mark a particular "moment in time" while we require to constantly keep different versions alive and update them. — lysergic-acid, Aug 08 '12 at 21:39

score 10 · Accepted Answer · answered Aug 09 '12 at 06:13

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.

awesome as always :) i thought you only deal with ClearCase :) — lysergic-acid, Aug 09 '12 at 07:13
@lysergic-acid by the look of my tags (http://stackoverflow.com/users/6309/vonc?tab=badges&sort=class), I deal with a bit more than ClearCase ;) — VonC, Aug 09 '12 at 07:15
Just that deleting branches in `git` is easy and painless, as is creating branches. So part of the pros of separate repositories dilute. — vonbrand, Feb 07 '13 at 01:41

score 1 · Answer 2 · edited May 23 '17 at 11:46

Here's an interesting answer using Git tags and branches from this Stack overflow question: https://stackoverflow.com/a/2714318/1552414 (answer by None-da)

Create a tag when you reach a new version. (v3.0.0)
Create a branch of it when you need to modify it for the first time
```
git checkout -b v3.0.0_branch v3.0.0 
```
Commit to the branch and create new tags when you reach v3.0.1, v3.0.2, v3.1.0

score 0 · Answer 3 · answered Jul 15 '15 at 18:24

Not too long ago my company went through a similar discussion (pros and cons of branches). While doing research I found the following instructional to be helpful. http://guides.beanstalkapp.com/version-control/branching-best-practices.html I hope it helps you as well.