Richtig, also muss ich herausfinden, ob GIT eine Lösung für ein bevorstehendes Problem sein würde. (Einfaches Erstellen von Feature-Verzweigungen, Hotfix-Verzweigungen, Bugfix-Verzweigungen, wobei die Leitung sauber gehalten wird und nur abgeschlossene Probleme (Feature, Hotfix, Bugfix usw.) vorhanden sind, damit nach der Freigabe keine halbfertigen / festgestellten Probleme mehr auftreten .
Zuvor verwendeten wir SVN mit einer modifizierten Version des Git-Flow / Branching-Modells, das hier vorgestellt wird: Ссылка Wo der git-master unser svn-trunk ist. Das funktioniert, ist aber mit SVN etwas umständlich. Zumal wir zwei gemeinsame Repositories verwenden.
Und hier kommt das Problem. Zuvor verwendeten wir diese beiden gemeinsam genutzten Repositories als externe Daten, und alle externen Referenzen wurden auf lib/a/branches/develop und lib/b/branches/develop verwiesen. Dies war umständlich, wenn ein Feature / Hotfix / Bugfix-Zweig benötigt wurde, weil es drei Zweige erstellen musste, das Superprojekt mit den neuen Referenzen modifizieren und dann die Änderungen festschreiben musste.
Nach einigem Hin und Her haben wir uns dazu entschlossen, Zweige der Bibliotheks-Repositories zu verwenden. (So, superProject/lib/a ist ein Zweig von lib/a/branches/develop ) und zukünftige Aktualisierungen (beide Wege) erfordern eine Zusammenführung entweder von superProject/lib/a in nach lib/a/branches/develop oder umgekehrt.
Dies löste jedoch immer noch nicht unser Problem mit halb fertiggestellten Commits, sobald eine Veröffentlichung in der Nähe war. (Und leider kann in der Firma, in der ich arbeite, dies in einer Stunde benötigt werden). Also dachten wir uns ein bisschen mehr und waren bereit, die von Atlassian zur Verfügung gestellten Tools ein wenig mehr zu testen, also Bitbucket (vorher Crucible / FishEye) auszuprobieren und ihren speziellen integrierten Workflow für Git zu verwenden, wo für jede Ausgabe ein Zweig sein kann erstellt und nach Fertigstellung kann eine Pull-Anfrage erstellt werden, so dass unser Release-Manager steuert, was reingeht und was nicht in der nächsten Version passiert. Keine Probleme mehr in /develop/ , da alle Probleme mit diesem Workflow gelöst werden.
Das Problem, vor dem ich stehe, ist, wie man diese gemeinsamen Projekte einbindet (Bibliothek a und b). Ich habe das Web gelesen und mehrere Seiten gefunden, die über Git-Submodule, Git-Subtree-Merging-Strategie, Git-Subtree (das Skript) und Manuelles Merging (ist das das Gleiche wie das Subtree-Merging?) Sprechen. Aber niemand beantwortet wirklich einige meiner Git-Newbie Fragen. Bis jetzt war ich am meisten von git-subtree fasziniert, aber die GUI-Unterstützung scheint miserabel zu sein. Weder TortoiseGit, noch SourceTree haben eine gute GUI-Unterstützung für git-subtree, was Befehlszeilen-Aktionen erfordert und die meisten Kollegen wissen, dass sie keine Kommandozeilen-Dinge machen wollen.
Was mich auch stört ist, dass es nichts Gutes gibt, was ich finden kann, Informationen darüber, aus welchem Repository / Zweig der Git-Teilbaum erstellt wurde und die Tatsache, dass ein Klon aus dem Remote-Git-Repository nicht git remote add -f libraryXXX http://repohere/lib-xxx.git (einmal) machen und dann git subtree pull --prefix locationGoesHere libraryXXX master (--squash optional)
Dies alles scheint so viel mühsamer als der Workflow für SVN mit dem Zusammenführen von Zweigen hin und her. Fehle ich etwas? Liest ich veraltete Informationen? Betrachte ich einfach nicht die korrekte Art, mit geteilten Repositories zu arbeiten?
Einige der Ressourcen, die ich verwendet habe:
Es ist schwierig, viele Aussagen zu Ihrem Setup zu machen, selbst wenn Sie die detaillierte Beschreibung angegeben haben. Allerdings kann ich sagen, dass Sie Verzweigungen in Git finden praktisch schmerzfrei sein (vor allem im Vergleich zu SVN). Ich empfehle die Verwendung von Submodulen für Ihre Bibliotheksabhängigkeiten. Sie sind nicht perfekt, aber sie arbeiten. Wenn Sie eine Verzweigung erstellen, beginnt diese Verzweigung mit der gleichen Version der Bibliotheken wie die übergeordnete Datei, und Sie können die .gitmodules -Datei bearbeiten, um andere zu verwenden. Sie müssen daran denken, einen neuen Klon mit dem --recursive -Flag zu erstellen (oder nach dem Klonen git submodule update zu verwenden), aber das ist viel einfacher als für Unterbäume.
Tags und Links git svn tortoisegit atlassian-sourcetree git-subtree
