Ich würde gerne einen beliebten Open-Source-Issue-Tracker (Redmine) verwenden, der Git-Integration bietet. Leider kann jedes Projekt im Tracker nur einem Git Repo zugeordnet werden. Das Erstellen mehrerer Projekte im Tracker ist nicht meine ideale Einstellung.
In diesem Sinne habe ich versucht, die Unterteilung von git-Unterbäumen zu verwenden (erklärt hier und hier ). Ich habe ein "Regenschirm" -Repo erstellt, das in jedem der zahlreichen anderen Repos zusammengeführt wurde, mit denen ich arbeite.
Leider ziehen die angegebenen Beispiele nur den Hauptzweig jedes Teilbaums. Da ich in mehreren Zweigen jedes Teilbaums Entwicklung habe, muss ich lernen, wie dieser Regenschirm-Repo jeden Zweig jedes Teilbaums widerspiegelt.
Ist das möglich?
Extra Credit: Was ist, wenn zwei Unterbäume jeweils einen Zweig mit demselben Namen haben?
Für diejenigen von uns, die nicht mit Redmine vertraut sind, erweitern Sie bitte Ihre Beschreibung, um Antworten auf die folgenden Fragen aufzunehmen: Welchen Zugriff auf das Repository benötigt der Tracker? Wird es eigene Commits machen müssen? Oder braucht es nur bestimmte Arten von Lesezugriff (vielleicht um Commit-Hashes zu validieren und Commit-Protokolle nach Schlüsselwörtern zu durchsuchen)?
Wenn Ihr Tracker nur Lesezugriff benötigt, brauchen Sie unter Umständen überhaupt keine Teilbaumverschmelzung. Es ist durchaus akzeptabel, mehrere Initial Commits (mehrere unabhängige Historien möglich) in einem einzigen Repository zu haben. Das Git-Projekt selbst tut dies für einige "Extras" ( man , html , todo ), die keine (commit) Historie teilen, aber sind Sie werden zusammen mit der Hauptgruppe der Zweige für den Quellcode veröffentlicht ( maint , master , nächstes , pu ). Zu Ihrem Zweck kann es ausreichen, für jedes Unter-Repository eine Remote einzurichten und deren Zweig-Tipps in Ihr aggregierendes Repository zu holen. Vielleicht reichen die automatischen Fernüberwachungszweige aus, oder Sie müssen den zusätzlichen Schritt ausführen, um lokale Zweigstellen basierend auf den Fernüberwachungszweigen zu erstellen (und zu aktualisieren).
Das von Ihnen beschriebene Teilbaumverschmelzungsschema ist wahrscheinlich nicht sinnvoll in der allgemeinen Situation, in der die Zweige in den Quellrepositorys nicht oder nur teilweise verwandt sind. Wenn jedoch alle Quell-Repositories eine Reihe von Zweigen teilen, in denen jeder Zweig einen bestimmten Zweck hat, der in allen Repositories derselbe ist, könnten Sie sie wahrscheinlich sinnvoll in eine Art Super-Repository zusammenführen.
Aber die interessante Frage ist nicht "Was ist, wenn zwei Repositories Zweige mit dem gleichen Namen haben?", sondern "Wie gehst du mit dem Fall um, in dem ein Repository eine Verzweigung aus der gemeinsamen, globalen 'Menge?" / p>
Wenn alle Unter-Repositories die gleichen Zweige haben, tun Sie einfach das, was Sie mit master gemacht haben, aber einmal für jeden Zweig. Das Problem tritt auf, wenn ein bestimmter Zweig in einem Repository fehlt. Du könntest seinen Master ersetzen, aber das ist vielleicht nicht immer die richtige Antwort. Es hängt davon ab, warum Sie die Repositories zusammen an erster Stelle aggregieren und was Sie in diesem Teilbaum dieses Zweiges im Super-Repository erwarten.
Wenn die Unter-Repositories nicht eng verwandt sind, dann habe ich wirklich Zweifel an der Angemessenheit dieses Teilbaum-Ansatzes. Ein solcher Ansatz für unabhängige Repositorien fühlt sich an, als würde er "gegen den Strich gehen". Es ist wahrscheinlich immer noch möglich, aber ich bezweifle, dass es ein Werkzeug gibt, um zu helfen, und Sie müssen einige Zeit damit verbringen, die Eckfälle zu planen.
Wenn Sie sich mit Teilbaumzusammenführungen zufriedengeben, können Sie sich die Drittanbieter ansehen git subtree Befehl. Es könnte helfen, Ihre unzähligen Repositories synchronisiert zu halten.
Wenn Redmine --mirror clone angibt, bedeutet dies, dass lokale Verzweigungen erwartet werden und die "Remote-Tracking-Zweige" möglicherweise nicht direkt gelesen werden können. Daher müssen Sie wahrscheinlich einige lokale Zweige erstellen und aktualisieren.
Ersteinrichtung
%Vor%Periodisches Update
%Vor%Ersteinrichtung
%Vor%Periodisches Update
%Vor% Beide Methoden enden damit, Zweige unter refs/heads/all/<remote-name>/<branch-name-on-remote> zu sammeln, aber die erste hat auch eine doppelte Menge an Referenzen unter refs/remotes/<remote-name>/<branch-name-on-remote> . Der erste verwendet einen normalen Fetch Refspec und verwendet git branch , um die 'Remote-Tracking-Zweige' ( refs/remotes/… ) in normale lokale Zweige ( refs/heads/all/… ) zu duplizieren. Der zweite verwendet eine benutzerdefinierte refspec, um die abgerufenen Refs direkt in der Zielref-Hierarchie zu speichern.
Aufgrund der Art und Weise, wie Updates blind in dieses kombinierte Repository geholt werden, sollte niemand versuchen, es direkt zu verwenden: keine Commits, die direkt auf seinen Zweigen gemacht werden, keine Pushs von außen. Wenn jemand lokal Commits macht oder auf eine der Filialen drückt, werden diese Commits gelöscht, wenn das nächste Update durchgeführt wird.
Wenn Redmine mit einem leeren Repository umgehen kann, würde ich empfehlen, eines zu verwenden. Verwenden Sie git init --bare und einen Repo-Namen, der mit .git endet. Auch git config core.logAllRefUpdates true könnte eine gute Idee sein (da dies in einem blossen Repository standardmäßig auf "false" gesetzt ist).
Neben dem all/ Präfix in den Namespaces besteht ein weiterer Unterschied zwischen diesem Ansatz und einem vollständigen --mirror Klon darin, dass Refs außerhalb von refs/heads und refs/tags nicht gesammelt werden. Die meisten anderen allgemeinen Referenzen werden als "lokal" für ein Repository angesehen (weshalb sie nicht von einem normalen Klon kopiert werden). Einige der anderen Refs sind "Remote-Tracking-Zweige" ( refs/remotes ), einige 'Halbe'-Aufzeichnungen ( refs/bisect ), git filter-branch ' Original'-Ref-Backups ( refs/original ) und so weiter. Wahrscheinlich ist keines dieser anderen Dinge wichtig für Redmine.Wenn sie es sind, können sie auch mit zusätzlichen refspecs enthalten sein.
Um einen Zweig mit einem neuen initialen Commit zu arrangieren, besuchen Sie die GitTips-Seite unter Wie man einen neuen Zweig erstellt, der keinen Vorgänger hat . Zwei der Rezepte beinhalten ein anderes Repository, von dem aus Sie nach dem normalen init / add / commit-Schritt eine Verzweigung drücken oder holen (genau das, was die obigen Rezepte auf automatisierte Weise tun).