Zu 1+2: Es gibt im VS eine Suche über alle Projektdateien, auch mit Mustervergleichen.
Dazu braucht man ein Masterprojekt, das dann auch Subprojekte enthalten kann, die dann alle durchsucht werden.
Am Beispiel eines ERP's habe ich ein Gesamtprojekt, das sich aber in Teilprojekte wie Auftragswesen, Bestellwesen u.v.m., aufteilen lässt, sowie einem weiteren Subprojekt für übergreifende Services.

Das Branch-Handling ist zugegeben sehr komplex, und bedarf natürlich einer gewissen Dispziplin.
Gehen wir von einem normalen Projekt aus, so kann jeder nur einzeln an einem Objekt arbeiten.
D.h., ich arbeite an ProgA mit DSPF A und ggf. weiteren Abhängikeiten, die das Programm betreffen.
Du kannst dann an ProgB arbeiten.

Gemeinsame Ressourcen wie die Datenbank (Tabellen, Views, Indexe, Trigger, Constraints, ...) werden je Objekt gezielt einzeln durchgeschossen, wie ich oben schon mal sagte, und könnten in einem eigenen Subprojekt liegen.

Mit Branches hat das noch nichts jzu tun.
Branches benötigt man für Releases des Gesamtprojektes, bzw. von Teilprojekten.
Dabei geht immer vom Kontext des Projekts und nicht der Objekte aus.

Wenn ich also ein Release V1 erstellt habe, das natürlich gestestet und stabil ist;-), kann ich das in einem Branch V1 fixieren.
Das aktuelle Projekt ist dann weiter das Entwicklungsprojekt.

Treten nun im freigegebenen V1 wider jeglicher Erwartung nun doch Fehler auf, dann behebe ich in V1 den Fehler, kann das dann in Echt als V1.1, ggf. als Branch, deployen.
Gemachte Ergänzungen merge ich dann ins aktuelle Projekt.

Jetzt habe ich also 3 Branches. An die Ableitungen V1, V1.1 arbeite ich erst mal nicht weiter.

Soweit nun die blanke Theorie.
Die Anzahl der Branches wird durch die Anzahl verschiedener Installationen bestimmt. Wenn die Version eines Branches nicht mehr installiert ist, kann ich diesen auch löschen.

Bei selbstprogrammierenden Anwendern reicht i.d.R die aktuelle Umgebung und genau 1 Branch der produktiven Umgebung um schnelle Korrekturen zu ermöglichen.