Git und Visual Studio Projekt verweist

Question

Alrighty dann wäre die kurze Version meiner Frage:

Was ist der beste Weg, Projektreferenzen in Git zu handhaben, wenn Sie Projekte, die über mehrere Lösungen gemeinsam genutzt werden und wie soll mein Git Repos organisiert werden?

Die lange Version ist:

Wir sind ein kleines Entwicklerteam (5-Entwickler) und zur Zeit verwenden wir TFS als unsere Quellcodeverwaltung und Build-Server und Visual Studio ist unser IDE der Wahl. Ich war schon immer daran interessiert, neue Dinge auszuprobieren und zu versuchen, unsere Entwicklungsumgebung zu verbessern, also entschied ich mich, Git zu lesen, um herauszufinden, ob es ein guter Ersatz für die Quellcodeverwaltung von TFS wäre. Wir haben Jira einfach in unseren Workflow integriert, also entschied ich mich, Stash als unsere Git-Umgebung auszuprobieren, weil es so gut in Jira integriert ist. Ich bin gerade dabei, herauszufinden, auf welche Weise ich die Git-Repos organisieren kann, und deshalb bin ich hier. Jetzt werde ich beschreiben, wie viele unserer Lösungen organisiert sind.

Wir haben eine Reihe von Lösungen bekommen. Einige sind Bibliotheken und andere sind Programme, die auf diese Bibliotheken über Projektreferenz in Visual Studio verweisen.

Also die Hauptsache, die mich verwirrt wäre, wie mit Bibliotheken umzugehen, die in vielen Lösungen referenziert werden?

Sollten wir mit der Versionierung unserer Bibliotheken beginnen und jede Bibliothek in einem separaten Repo ablegen? Es scheint, als würde dieser Weg eine Menge zusätzlicher Wartung erfordern, wenn eine Bibliothek ein Update erhält, das bereitgestellt werden muss, und diese Bibliothek von mehr als 20 Lösungen verwendet wird. Liege ich falsch ? Ein weiterer Nachteil, den ich sehe, ist, dass es in Visual Studio keine Projektreferenzen mehr geben würde und das Debugging viel mühsamer würde.

Sollte ich mit all unseren Lösungen nur ein großes Repo machen und auf diese Weise alle unsere Referenzen auf dem neuesten Stand halten?

Ich dachte auch, dass vielleicht könnte ich unser eigenes nuget Repository machen, die alle Thesen Bibliotheken und so hat es nicht so viel von einem Streit würde die referenzierten Bibliotheken zu aktualisieren, wenn nötig. Dies ist nur eine Idee und ich habe mich nicht gründlich damit befasst, also bin ich mir nicht sicher, ob dies von Vorteil wäre.

Also, gibt es Menschen gibt, die mir einige Ratschläge in Bezug auf diese geben könnte?

Answer 1

Dies ist eine dieser Fragen, die leider keine einzige Antwort hat - es kommt darauf an.

Die einfachste Lösung ist immer ein einziges Repository zu haben. Dies vermeidet viele der Probleme beim Verwalten mehrerer Repositories mit unterschiedlichen Versionen. Aber das funktioniert nur, wenn Sie eine einzige Version von allem haben; Es ist fast unmöglich, unterschiedliche Release-Zyklen für zwei Produkte im selben Repository zu haben. So liegt der Wahnsinn. Wenn Repositories zu irgendeiner nicht signifikanten Größe wachsen, skaliert sie auch nicht wirklich.

Wie Till darauf hinweist, ist eine Option Git Submodules. Dadurch können Sie die Quelle eines Repositorys in einem anderen bei einer bestimmten Festschreibung oder Verzweigung dynamisch laden. Natürlich kommt dies mit einer ganzen host of problems, einig spezifischen so Submodule und andere nur die Art der Verknüpfung von Repositories sind. *

wirklich einige Leute wie Git Subtree, die etwas Betrug ist und läßt Dich immer wieder extrahieren und dann die Geschichte eines importieren Ordner über Repositories und wieder zurück.

Schließlich können Sie abhängig von Ihrer Build-Umgebung auf ein Abhängigkeitsverwaltungstool zurückgreifen. Ich weiß nicht genug über Visual Studio, um etwas zu kommentieren. Bei Atlassian benutzen wir (derzeit) Maven, um das zu lösen. Wenn Sie JS verwenden, könnte es NPM/Bower sein, bei Ruby ist es Gems. Es kann frustrierend sein, eine neue Version von Library X zu veröffentlichen, nur um eine geringfügige Änderung für Programm Y zu machen, aber größtenteils funktioniert es gut genug.

Das ist wirklich ein andauerndes Problem, und etwas, das ich kenne, ärgert mich jeden Tag. Ich habe das Gefühl, dass es eine Möglichkeit für eine bessere Lösung geben könnte, die das Beste aus Submodulen und Abhängigkeitsmanagement kombiniert, aber ich habe es noch nicht gefunden.

Ich hoffe, dass hilft?

* Meine eigene größte Beschwerde mit Submodulen, abgesehen von Tooling-Problemen, ist, dass es Leute ermutigt, absolute URLs zu anderen Repositories einzuchecken. Dies funktioniert perfekt, bis Sie sich entscheiden, Ihren Git-Server oder eines der Repositories zu migrieren, und jetzt ist alles kaputt. Ich habe neulich herausgefunden, dass Sie relative paths verwenden können, was ordentlich ist, aber das Problem nicht löst.