Unser Team ist gerade dabei, von SVN zu Git zu wechseln. Wir verwenden Maven derzeit als unser Build-Tool.
Gegenwärtig haben unsere Projekte eine Build-Hierarchie durch Maven, sind aber auf der Dateihierarchie / Repository-Seite flach. Mein Ziel ist es, die Maven-Build-Hierarchie und die Dateistrukturhierarchie in unseren Repositories besser aufeinander abzustimmen, um alles besser zu verstehen.
Meine Frage ist, was ist die richtige Ebene, um Git Repos zu erstellen, so dass die Dateihierarchie / Organisation beibehalten wird? Beispiel:
- Big Project - (keine Quelle hier, nur ein Pom)
- Back-End-Projekt (source + pom)
- Kunden (keine Quelle hier, nur ein Pom)
- Konsole (source + pom)
- Web (Quelle + Pom)
Also würde das "pom only" -Projekt verwendet werden, um tatsächliche Quellprojekte zu gruppieren. Aber wo gehört das Git Repo? Einige Teammitglieder sind besorgt, dass die Commits für das Web -Projekt nicht in die Historie für das Console -Projekt gehören. Aber wenn sich die Git-Repos auf den niedrigsten Ebenen befinden (die Blattknoten des Baumes), verlieren wir die Organisation der Dateistruktur (obwohl die Build-Hierarchie in Maven beibehalten werden kann).
Bearbeiten: Die Bedenken des Teammitglieds bestanden nicht so sehr in der Commit-Historie als in Tagging. Da der Repo-Stamm von Git im Big Project ist und ich das Web -Projekt (durch Markieren des Big Project ) taggen möchte, warum Soll dieses Tag das Console -Projekt enthalten, das möglicherweise nicht für das Web -Tag relevant ist?
Ich habe ein Maven-Projekt, das aus über 60 Modulen besteht, und mein Team hat die gleiche Frage diskutiert, wo genau die Git-Repository-Wurzeln sein sollten. Bis jetzt ist jede Diskussion damit beendet, das gesamte Projekt bis zum Root Pom im selben Projekt zu belassen. Die Entscheidung basiert hauptsächlich auf der Bequemlichkeit von Entwicklern - wir müssen nicht mehrere verschiedene Repositories klonen und öffnen, um in einem im Wesentlichen gleichen Projekt zu arbeiten. Die Frage nach der Geschichte erscheint mir falsch. Wen interessiert es, wenn die Geschichte vermischt wird? Sie können immer den Verlauf einer bestimmten Datei / des Moduls / Pfads in git sehen, ausschließlich anderer.
Eine Option, die wir in Betracht gezogen haben, ist etwas, das git Submodule genannt wird lassen Sie Repos in Repos einbetten. Dies könnte eine Option zum Organisieren Ihrer Hierarchie sein, wenn Sie sich entschließen, sie zu trennen.
Ich würde vorschlagen, die Struktur in Git genauso wie in SVN zu belassen, was ein einzelnes Git Repos mit dem gesamten Projekt bedeutet. Der Punkt ist, dass Sie das Maven-Release-Plugin ohne Probleme für solche Arten von Multi-Modul-Builds verwenden können.
Tags und Links maven git organization structure tagging