Git-Zweige mit komplett anderem Inhalt

Question

Da Git die Fähigkeit besitzt, Zweige mit völlig unterschiedlichem Inhalt im selben Repository zu verfolgen (und sauber zu halten), haben einige Projekte (wie Git selbst) begonnen, diese zu nutzen davon.

Git zum Beispiel verwendet einen Zweig für den Code selbst, während seine Dokumentation in einem separaten Zweig bleibt. Gleiches Repo, nur verschiedene Zweige.

Vielleicht bin ich es, der aus einem SVN-Hintergrund kommt, aber ich finde es verwirrend, in diesen Zweigen nichts gemeinsam zu haben. Entwicklung/Inszenierung/Produktion Filialen; die ich verstehe. Verzweigungen für unvollständige Merkmale; Sicher, ich mache das auch. Heck, haben Sie Ihre Dokumentation mit einer Verzweigung pro Sprache. Aber keine gemeinsamen Dateien?

Ist dies nur ein (vielleicht ein wenig genutztes und/oder unterbewertetes) Feature in Git, an das sich alle gewöhnen sollten, oder ein möglicherweise gefährlicher Missbrauch durch jemanden, der faul ist, zwei Aspekte desselben Projekts nicht ausreichend zu unterscheiden?

Answer 1

Ich persönlich würde nicht unterschiedliche Inhalte in verschiedenen Branchen speichern; im Fall von Dokumenten und Code würde ich einfach ein myproject.git und ein myproject-docs.git machen (und die Dokumente in den Code unterteilen, wenn es für den Build-Prozess notwendig war).

Auf der anderen Seite wird nichts Schlimmes passieren, wenn Sie dies tun. Git sagt dir nicht, was du tun sollst, also kannst du deine eigene Entscheidung darüber treffen, wie du es benutzen willst. Also, um deine Frage zu beantworten, ist es weder ein Killermerkmal noch etwas, das dich umwerfen wird, wenn du nicht vorsichtig bist. Es ist nur, wie jemand sich entscheidet, es zu benutzen.

Answer 2

Der Vorteil, dies zu tun, ist, dass es möglich ist, nur den Docs-Zweig zu ziehen, wenn das alles ist, was Sie interessiert. Wie jrockway sagte, können Sie dies mit einem anderen Repository und Submodulierung bei Bedarf tun, aber mit dieser Fähigkeit zu Erstellen Sie einen 'nackten' Zweig, Sie haben die Option nicht zu.

Persönlich bin ich immer noch auf dem Zaun darüber. Ich verstehe, warum es nützlich sein könnte, aber ich bin nicht ganz davon überzeugt, dass es der beste Weg ist.

Answer 3

Es ist ein bisschen komisch, wenn Sie mit dem Subversion-Modell vertraut sind, den Benutzer den Baum zu präsentieren, aber sobald Sie sich an das Modell gewöhnen, ist es viel weniger verwirrend.

Ein Git-Repository ist nur eine Baumstruktur von Objekten, die erklären, wie ein Verzeichnis von einem Zustand in einen anderen umgewandelt wird. Diese Objekte haben einen Elternteil. Einige Objekte haben zwei (oder mehr) Eltern; verschmilzt. Einige Objekte haben keine Eltern; das anfängliche Commit.

Wie ich es verstehe, intern ist Subversions Modell ähnlich minus das Konzept, wo Merges herkam. Das sind nur neue Commits mit einem praktischen Befehl (svn merge), um ein Patch der Unterschiede zwischen zwei anderen Commits zu erhalten.

Ich benutze diese Funktion ziemlich oft, um Konfigurationsdateien zu verwalten, die von demselben Verzeichnis auf separaten Hosts gestartet wurden, wie /etc/apache2. Es ist so, als würde man sagen: "Dies ist der alternative Anfang dieses Stoffes, aber er wurde aufgegeben". Es erlaubt mir, den Zustand einiger Dateien zu speichern, bevor ich sie überschreibe, ohne mich darum kümmern zu müssen, ob sie richtig zusammengeführt werden oder überhaupt mit dem Master-Zweig zusammenhängen.

In Subversion müsste ich diese Sicherung an einem nicht verwandten Ort (zip-Datei irgendwo) oder in einem Unterverzeichnis im Repository speichern. Wenn ich in Subversion einen Verweis auf diese Dateien in der aktuellen Ansicht des Baums lösche, wird es sehr schwierig, sie wieder zu finden.

Answer 4

Ich würde sagen, dass es für die Tatsache, wie eine faule Abhilfe mehr ist, dass Git im gleichen Repository mehrere Projekte behandeln gespeichert sind derzeit nicht kann. Sie können es tun, aber es gibt keine Möglichkeit, nur das gewünschte herunterzuziehen.

ich sage „faul“, weil es nicht zu schrecklich hart gewesen wäre, die Funktion, wenn die git Entwickler selbst eine Notwendigkeit für sich entdecken (zum Speichern docs) hinzuzufügen. Seit sie diesen seltsamen Branch-Hack benutzt haben, ist ihr Ansporn, das Problem für alle anderen zu lösen, deutlich zurückgegangen.

Answer 5

Ich denke, es hängt davon ab, was Ihr Projekt ist.

Git ist offensichtlich ein OSS-Community-Projekt, so die Dokumentation, die in der (gleichen) Repository, so dass jeder bekommt sie Sinn (für mich) macht.

Auf der anderen Seite ich bei der Arbeit, die Dokumentation für meine Projekte nicht speichern würde, wie ich sie außer bearbeiten auf rarley würde ‚Lassen Sie sich die Dokumente aktualisieren‘ die Art der Fahrkarte. Bei der Arbeit möchte ich nicht, dass meine Dokumente mit meiner Quelle vermischt werden, ich möchte nur die Quelle (typische Programmiereransicht, die ich kenne).

Andere mögen sie alle zusammen wollen. Ich denke, Sie müssen nur verstehen, was es bedeutet (denken Sie daran, jeder hat eine vollständige Kopie des Repository) und wählen Sie die beste Option für Ihr Projekt.

Answer 6

Git verfolgt koordiniertee Änderungen (Text) Dateien innerhalb eines Projektes, so dass er nicht weiß, oder egal, ob Zweig mergable oder nicht. Unabhängige Zweige in einem Git-Repo zu haben, ist vergleichbar mit unabhängigen Projekten in einem Subversion-Repo, was allgemein üblich ist (wegen des Overheads von svn).

Weil Git Datenstruktur ganz anders als SVN ist, können Sie mit ihnen verschiedene Dinge zu tun. In SVN ist ein Feature Branch etwas ungewöhnlich, und ein Feature Branch, der nicht oft mit dem Trunk zusammengeführt wird, könnte ein "schlechter Geruch" sein, ein Zeichen, dass der Programmierer "dunkel geworden" ist und Code erzeugt, der niemals sein könnte in das Projekt integriert. In Git ist ein Feature-Zweig ein vollkommen sicherer und vernünftiger Workflow.

So können sie auf verschiedene Arten verwendet werden, weil Git nicht SVN ist, obwohl beide Repositories und Zweige und Commits haben, und dienen der gleichen allgemeinen Funktion der Quellcodeverwaltung.

Da habe ich mehr Erfahrung mit Git, was verschiedenen wurde nur seltsam gewesen war. Dann wurde ich neugierig, was ich mit diesem anderen Werkzeug machen könnte.