Flexible vs. statische Verzweigung (Git vs. Clearcase/Accurev)

StackOverflow https://stackoverflow.com/questions/763099

Frage

Meine Frage betrifft die Art und Weise, wie Git mit Zweigen umgeht:Wenn Sie von einem Commit aus verzweigen, erhält dieser Zweig niemals Änderungen vom übergeordneten Zweig, es sei denn, Sie tun dies Gewalt es mit einer Zusammenführung.

Aber in anderen Systemen wie Clearcase oder Accurev können Sie festlegen, wie Zweige gefüllt werden eine Art Vererbungsmechanismus:Ich meine, mit Clearcase kann man mit einer config_spec sagen: „Alle Dateien im Zweig /main/issue001 ändern und dann mit denen in /main oder mit dieser spezifischen Baseline fortfahren.“

In Accurev gibt es auch einen ähnlichen Mechanismus, der es Streams ermöglicht, Änderungen von oberen Zweigen (Streams, wie sie sie nennen) zu empfangen, ohne sie zusammenzuführen oder einen neuen Commit für den Zweig zu erstellen.

Vermissen Sie das nicht, wenn Sie Git verwenden?Können Sie Szenarien aufzählen, in denen dies der Fall ist? Nachlass ist ein Muss?

Danke

Aktualisieren Bitte lesen Sie die Antwort von VonC unten, um meine Frage konkret zu fokussieren.Sobald wir uns einig sind, dass „linearer Speicher“ und DAG-basierte SCMs unterschiedliche Fähigkeiten haben, lautet meine Frage: Welches sind die realen Szenarien (insbesondere für Unternehmen, die mehr als OSS sind), in denen Linear Dinge tun kann, die für DAG nicht möglich sind?Sind sie es wert?

War es hilfreich?

Lösung

Um zu verstehen, warum Git nicht eine Art bieten, was Sie sich beziehen, als „Vererbungsmechanismus“ (ohne Beteiligung eine Festschreibung), müssen Sie zunächst ein Verständnis der core Konzepte jener SCMs (Git vs. Clearcase zum Beispiel)

  • Clearcase verwendet eine lineare Version Lagerung : jede Version eines Elements (Datei oder Verzeichnis) in einem direkten verknüpfen linear Beziehung mit der vorherige Version das gleiche Element.

  • Git verwendet eine DAG - gerichteter azyklischer Graph : jede „Version“ einer Datei tatsächlich Teil einer globalen Reihe von Änderungen in einem Baum ist, der sich als Teil eines begehen ist. Die vorherige Version, dass in einem früheren verpflichten, die über einen einzigen gerichteten azyklische Graph Weg gefunden werden muss.

In einem linearen System, eine Config-Spezifikation mehr Regeln für die Erreichung der „Vererbung“ angeben können Sie sehen (für eine bestimmte Datei, zuerst eine bestimmte Version auszuwählen, und falls nicht vorhanden, dann eine andere Version auszuwählen, und falls nicht vorhanden, dann eine dritte wählen, und so weiter).

Der Zweig ist ein Gabel in einem linear Geschichte eine bestimmte Version für eine bestimmte Auswahlregel (alle anderen Auswahlregeln vor, dass man nach wie vor gelten, damit die „Vererbung“ -Effekt)

In einer DAG, ein Commit repräsentiert all das „Erbe“ Sie jemals bekommen werden; es gibt keine „kumulative“ Auswahl von Versionen. Es gibt nur einen Weg in diesem Diagramm alle Dateien auszuwählen, die Sie an diesem genauen Punkt sehen (Commit).
Ein Zweig ist nur ein neuer Weg in diesem Diagramm.

anwenden zu können, in Git, einige andere Versionen, müssen Sie entweder:

Aber da Git ein DAG-basierter SCM ist, wird es immer in einem neuen Folge begehen.

Was Sie „verlieren“ mit Git sind, ist eine Art „Komposition“ (wenn Sie verschiedene Versionen mit unterschiedlichen aufeinanderfolgenden Auswahlregeln Auswahl), aber das würde in einem D VCS nicht praktikabel sein ( wie in „Distributed“): wenn Sie einen Zweig mit Git machen, müssen Sie so mit einem Startpunkt tun und ein Gehalt klar definiert und leicht auf andere Repositories repliziert

.

In einem rein zentralen VCS, können Sie Ihren Arbeitsbereich definieren (in Clearcase, Ihre „Ansicht“, entweder Schnappschuss oder dynamisch) mit dem, was Regeln, die Sie wollen.

unknown-google im Kommentar hinzufügt (und in seiner Frage oben):

  

Also, wenn wir die beiden Modelle sehen verschiedene Dinge erreichen können (linear vs DAG), meine Frage ist: Welches sind die realen Situationen (vor allem für Unternehmen mit mehr als OSS), wo lineare Dinge für DAG nicht möglich machen kann? Sind sie es wert?

Wenn es um die „Real-Life-Szenario“ in der Bezeichnung der Auswahlregeln, was Sie in einem linearen Modell tun können, ist zu haben, mehrere Auswahlregeln für den gleichen Satz von Dateien .

Betrachten Sie diese "config spec" (das heißt "Konfigurationsspezifikation" für Auswahlregeln mit Clearcase): 

element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch

Sie wählt alle Dateien markiert ‚aLabel2‘ (und Zweig von dort), mit Ausnahme derjenigen der Bezeichnung ‚aLabel3‘ - und Niederlassung von dort - (weil diese Regel vorausgeht the ein erwähnen 'aLabel2').

Ist es das wert?

Nein.

Eigentlich ist der UCM Geschmack von Clearcase (die „ Unified-Konfiguration Management “Methodik mit dem Clearcase Produkt enthielt, und stellvertretend für alle‚best practices‘abgeleitet von der Basis Clearcase-Nutzung) erlaubt es nicht, aus Gründen der simplificity . Eine Reihe von Dateien wird eine „Komponente“ genannt, und wenn Sie wollen für ein bestimmtes Etikett (als „Baseline“ bekannt) verzweigen, die wie diese folgenden Config spec übersetzt werden würden: 

element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch

Sie müssen wählen ein Ausgangspunkt (hier 'aLabel3') und gehen von dort aus. Wenn Sie die Dateien auch von ‚aLabel2‘ wollen, machen Sie eine Zusammenführung von allen ‚aLabel2‘ Dateien zu den in ‚myNewBranch‘.

Das ist ein „Vereinfachung“ Sie müssen nicht mit einer DAG machen, wobei jeder Knoten des Graphen für einen Zweig einen eindeutig definierten „Ausgangspunkt“ darstellt, was auch immer der Satz von Dateien beteiligt ist.

Merge und rebase sind genug, um diesen Ausgangspunkt mit anderen Versionen einer gegebenen Menge von Dateien zu kombinieren, um die gewünschten „Zusammensetzung“, zu erreichen, während dieser bestimmte Geschichte zu halten in Isolation in einem Zweig .

Das allgemeine Ziel der Vernunft in ist " kohärenter Operationen Versionskontrolle auf eine kohärente Komponente". Ein „kohärent“ Satz von Dateien ist ein in einem gut definierten kohärenten Zustand:

  • , wenn markiert, alle seine Dateien werden markiert
  • wenn verzweigt, alle seine Dateien aus dem gleich einzigartigen abzweigt Ausgangspunkt

Das ist leicht in einem DAG-System durchgeführt; es kann (mit „Basisclearcase“, wo die „config spec“ schwierig sein kann vor allem) in einem linearen System schwieriger sein, aber es wird mit der UCM Methodik des gleichen linearem basierten Werkzeugs durchgesetzt werden.

Statt dass „Zusammensetzung“ durch eine „private Auswahlregel Trick“ (mit Clearcase, einige wählen Sie die Reihenfolge der Regeln) zu erreichen, erreichen Sie es nur mit VCS-Operationen (rebase oder fusionieren), die eine klare Spur für alle verlassen zu folgen (im Gegensatz zu einer Config-spec privat zu einem Entwickler oder unter einigen geteilt, aber nicht alle Entwickler). Auch hier setzt es einen Sinn von Kohärenz , als auf eine „dynamische Flexibilität“ gegenüber, dass Sie eine harte Zeit später zu reproduzieren können .

Das erlaubt Ihnen, das Reich der VCS (Version Control System) zu verlassen, und geben Sie die Reich des SCM (Software Configuration Management) , die vor allem mit „ Reproduzierbarkeit “. Und das (SCM-Funktionen) mit einem linear-basierten oder einem DAG-basierten VCS erreicht werden.

Andere Tipps

Es klingt wie das, was Sie suchen sein könnte git rebase . Rebasing einen Zweig löst konzeptionell es von seinem ursprünglichen Verzweigungspunkt und reattaches es an einem anderen Punkt. (In Wirklichkeit ist das Fütterungsmaterial durch die Anwendung jedes Patch der Branche in Folge auf den neuen Verzweigungspunkt durchgeführt wird, eine neue Reihe von Patches zu erstellen.) In Ihrem Beispiel können Sie einen Zweig auf die aktuelle Spitze eines oberen Zweiges rebase, die im wesentlichen „erbt“, um alle auf den anderen Zweig vorgenommenen Änderungen.

Ich bin mir nicht ganz klar, was für Ihre fragen, aber es klingt wie Git Tracking-Semantik sind, was Sie wollen. Wenn Sie von am Ursprung verzweigen Sie können, wie etwas tun:

git -t -b my_branch origin / master

Und dann Zukunft „git pull“ s wird automatisch fusionieren Herkunft / Master in Ihrem Arbeitszweig. Sie können dann „git cherry -v origin / master“ verwenden, um zu sehen was ist der Unterschied. Sie können „git rebase“ verwenden, bevor Sie veröffentlichen Ihre Änderungen, die Geschichte zu bereinigen, aber man sollte einmal nicht verwenden rebase Ihre Geschichte ist öffentlich (das heißt andere Menschen nach diesem Zweig werden).

In Bezug auf das Vererbungsschema von AccuRev verwendet: GIT Benutzer werden wahrscheinlich „get“ die ganze Sache, wenn der Blick auf git-flow (siehe auch: http://github.com/nvie/gitflow und http://jeffkreeftmeijer.com/2010/why-arent- Sie betriebener-git-flow / )

Diese GIT Verzweigung Modell mehr oder weniger tut (manuell / mit Hilfe des git-Flow-Tool), welche AccuRev tut out-of-the-Box automatisch und mit groß GUI-Unterstützung.

So

es erscheint GIT kann tun, was AccuRev tut. Da ich eigentlich git / git-Flow-Tag-zu-Tag nie verwendet wird, kann ich nicht wirklich sagen, wie es funktioniert, aber es vielversprechend aussieht. (Minus richtige GUI-Unterstützung: -)

Ich werde versuchen, Sie beantwortende Frage. (Ich habe hier zu sagen, dass ich nicht nur benutzt haben GIT darüber gelesen, so dass, wenn etwas, das ich unten erwähnen falsch ist, bitte korrigieren Sie mich)

"Können Sie Szenarien aufzählen, wo dieses Erbe ist ein Muss?"

Ich will nicht sagen, es ist ein Muss, weil Sie ein Problem mit dem Werkzeug lösen können Sie haben, und könnten eine gültige Lösung für Ihre Umgebung sein. Ich denke, es ist eine Frage der Prozesse als das Werkzeug selbst. Sicherstellen, dass Ihr Prozess ist kohärent und ermöglicht auch in der Zeit gehen Sie zurück irgendwelche Zwischenschritt / Zustand zu reproduzieren, ist das Ziel, und der Vorteil ist, dass das Tool können Sie führen Sie Ihren Prozess und SCMP so schmerzlos wie möglich

Das einzige Szenario, das ich sehen kann es praktisch ist, diese zu haben, ‚Vererbung‘ Verhalten und nutzen die Kraft der config spec, ist, wenn Sie Ihren Satz von Änderungen „wollen getrennt “auf eine Aufgabe zugeordnet (devtask, CR, SR, oder was auch immer den Zweck / Umfang Ihrer Änderung Satz definiert)

Mit dieser Zusammensetzung können Sie Ihre Entwicklung astrein und noch andere Kombination (mit Zusammensetzung) verwenden haben, der Rest des Codes, und haben immer noch nur das, was für die Aufgabe relevant ist in einem isoliert Zweig während der ganzen Lebenszyklus der Aufgabe, gerade bis der Integrationsphase.

Als Purist / merge zu begehen mit / rebase nur einen „definierten Ausgangspunkt“ zu haben, ich denke, es wäre ‚ verschmutzt ‘ Ihre Niederlassung und Sie werden mit Ihren Änderungen + anderen Änderungen am Ende in Ihre Branche / Änderungsset.

Wann / Wo diese Isolation geeignet? Die Punkte unten könnte nur dann Sinn, auf den Kontext von Unternehmen machen verfolgen CMM und einige ISO-Zertifizierungen und könnte für eine andere Art von Unternehmen oder OSS

nicht von Interesse sein

  • Als wirklich pingelig, mögen Sie vielleicht genau die Codezeilen (hinzugefügt / geändert / gelöscht) des Änderungsset zählen zu einem einzigen Entwickler entspricht, später als einen Eingang für Code und Aufwandsschätzungen verwendet.

  • Es kann einfacher sein, den Code in den verschiedenen Phasen zu überprüfen, in einem einzigen Zweig nur Ihren Code (nicht mit anderen Änderungen geklebt)

Auf großen Projekten mit mehreren Teams und +500 Entwickler aktiv gleichzeitig auf demselben Basiscode arbeiten, (wo grafische einzelne Element Version Bäume sieht aus wie eine chaotische Gewirr mit mehreren Lastkennlinien, eine für jeden großen Kunden oder eine für jede Technologie ) große Konfigurationsdaten Zusammensetzung von einigen Grad in der Tiefe unter Verwendung gemacht, diese Menge an Menschen nahtlos arbeiten, um das gleiche Produkt / System (Basiscode) zu unterschiedlichen Zwecken anzupassen. Mit dieser Konfiguration spec, gab dynamisch jedes Team oder Unter Team, eine andere Sicht auf das, was sie brauchen, und von wo aus sie müssen zur Verzweigung, (Kaskadierung von mehreren Fällen) ohne die Notwendigkeit von Zwischen Integration Zweige zu schaffen, oder ständig Zusammenführung und Umbasierung alle die Bits, die Sie brauchen, um mit. Code aus dem gleichen Aufgabe / Zweck wurde Verzweigung verschiedener Etiketten aber sinnvoll. (Sie können hier argumentieren die ‚bekannte Baseline‘ als Prinzip der SCM aber einfache Etiketten in einem schriftlichen SCM-Plan erwogen, haben die Arbeit) Es muss möglich sein, dies zu lösen mit GIT (Ich denke, in einem nicht dynamisch), aber ich finde wirklich schwer, ohne dieses ‚Vererbung‘ Verhalten Bild. Ich denke, den Punkt erwähnt durch VonC „wenn verzweigt, alle seine Dateien mit dem gleichen einzigartigen Ausgangspunkt verzweigen“ wurde hier gebrochen, aber daneben auch auf der SCMP dokumentiert wurde, ich erinnere mich gab es starkes Geschäft Grund, es so zu tun.

Ja Bau diese Konfigurationsdaten, die ich oben erwähnt war nicht frei, am Anfang dort, wo 4-5 gut bezahlte Menschen hinter dem SCM aber wurden später durch automatisierte Skripte reduziert, die Sie gefragt, was Sie über die Bedingungen der Etiketten / branches wollen / Merkmale und die CS für Sie schreiben.

Die Reproduzierbarkeit hier wurde nur erreicht zusammen mit der Aufgabe, die Config Spec Speicher in derdevTask System, so dass jede Aufgabe stromaufwärts nach Anforderungen abgebildet, und stromabwärts zu einem Config-spec abgebildet, ein eine Reihe von Änderungen (Code-Dateien, Konstruktionsunterlagen, Prüfungsunterlagen usw.)

So up einen Schluss hier hier auch sein mag, nur dann, wenn Ihr Projekt ist groß / kompliziert genug (und Sie können entlang der Laufzeit des Projektes SC Manager leisten :)) dann nur Sie anfangen zu denken, wenn Sie die ‚Vererbung brauchen Verhalten oder wirklich vielseitiges Werkzeug, sonst werden Sie direkt zu aa Werkzeug gehen, das frei ist und bereits die Kohärenz kümmern Sie SCM ... aber es könnten auch andere Faktoren auf die SCM-Tool sein, dass Sie halten Sie sich an einen oder zum anderen ... weiter lesen ..

machen könnte

Einige Randnotizen, die möglicherweise aus Thema sein, aber ich denke, in einigen Fällen wie bei mir in Betracht gezogen werden müssen.

Ich habe hier hinzufügen, dass wir den „good-ol CC“ nicht UCM verwenden. Völlig einverstanden mit VonC auf die eine gute Methodik erlaubt „Führer“ die Flexibilität, auf eine kohärentere Konfiguration . Die gute Sache ist, dass CC ziemlich flexibel ist, und Sie können eine gute Möglichkeit, kohärent zu haben, was finden (nicht ohne Anstrengung), während in anderen SCM Sie es kostenlos haben könnten. Aber zum Beispiel hier (und anderen Orten, die ich mit CC gearbeitet habe) für C / C ++ Projekte können wir den Preis nicht leisten, nicht mit der winkin Funktion (die Ableitungs Objekte wiederverwendet), die Verringerung mehr X mal Kompilieren Zeit. Es kann argumentiert werden, dass ein besseres Design, ein mehr entkoppelten Code und Optimierung von Makefiles die Notwendigkeit zu reduzieren, die ganze Sache zu kompilieren, aber es gibt Fälle, die Sie brauchen das ganze Tier mehrmals am Tag zu kompilieren, und die gemeinsame Nutzung der DO spart Haufen von Zeit / Geld. Wo bin ich jetzt versuchen wir so viel kostenloses Tool wie möglich zu verwenden, und ich denke, wir los CC erhalten, wenn wir einen günstigeren oder kostenloses Tool finden können, die implementiert winkin Funktion.

ich mit etwas fertig werden, dass Paul erwähnen, verschiedenen Werkzeuge sind besser, dass andere für verschiedene Zwecke , aber ich will hinzufügen, dass Sie weg einen zusammenhängenden Prozess von einer Einschränkung des Werkzeugs erhalten können, indem man und ohne Aufreißen Reproduzierbarkeit, wichtige Punkte vor der SCM Am Ende denke ich die Antwort auf es wert ist? , hängt von Ihrem „Problem“, das SDLC Sie ausführen, Ihre SCM-Prozesse, und wenn es eine zusätzliche Funktion (wie winkin) ist das auch sein mag nützlich in Ihrer Umgebung.

my 2 cents

Abgesehen von der Theorie gibt es hier eine offensichtliche praktische Sichtweise aus meiner Sicht, in der ich AccuRev seit einigen Jahren in einer kommerziellen Produktionsumgebung verwende:Das Vererbungsmodell funktioniert sehr gut, solange die untergeordneten Streams nicht zu stark von den Vorfahren abweichen, die sich noch in der Entwicklung befinden.Es bricht zusammen, wenn die erbenden Streams zu unterschiedlich sind.

Durch Vererbung (spätere Versionen als untergeordnete Versionen früherer Versionen) können Änderungen in Ancestor-Streams in untergeordneten Streams aktiv werden, ohne dass jemand etwas unternehmen muss (es sei denn, eine Zusammenführung ist erforderlich. In diesem Fall wird eine tiefe Überlappung angezeigt, was gut sichtbar ist ).

Das hört sich großartig an und ist es auch in der Praxis, wenn alle beteiligten Streams relativ ähnlich sind.Wir verwenden dieses Modell für Hotfix- und Service Pack-Level-Streams unterhalb einer bestimmten Produktionsversion.(Für uns ist es tatsächlich etwas komplizierter, aber das ist die allgemeine Idee.)

Produktionsversionen erfolgen parallel, ohne Vererbung, mit den jeweils untergeordneten Hotfix- und Service Pack-Versionen.Das Starten einer neuen Version bedeutet, einen neuen Release-Level-Stream zu erstellen und alles aus dem neuesten Wartungsstream für die vorherige Version manuell hineinzuschieben.Danach müssen Änderungen an früheren Versionen, die für spätere Versionen gelten, manuell in jede einzelne Version eingefügt werden, was mehr Arbeit erfordert, aber eine viel bessere Kontrolle ermöglicht.

Ursprünglich haben wir das Vererbungsmodell für alle Versionen verwendet, wobei spätere Versionen untergeordnete Elemente früherer Versionen waren.Das funktionierte eine Zeit lang gut, wurde aber mit der Zeit unkontrollierbar.Große architektonische Unterschiede zwischen den Versionen machten die zwangsläufige Übernahme von Änderungen zu einer schlechten Idee.Ja, Sie können einen Snapshot dazwischen einfügen, um die Vererbung zu blockieren, aber dann müssen alle Änderungen manuell gepusht werden, und der einzige wirkliche Unterschied zwischen Parent-Snapshot-Child- und parallelen, nicht ererbenden Streams besteht darin, dass die gesamte grafische Stream-Ansicht kontinuierlich nach unten gepusht wird und rechts, das ist ein PITA.

Eine wirklich schöne Sache an AccuRev ist, dass Sie jederzeit diese Wahl haben.Dies ist keine inhärente Einschränkung der Architektur Ihres SCM-Programms.

Haben Sie bemerkt, dass Sie specfific Dateiversionen mit GIT Prüfung können?

Verwenden Sie einfach diese: 

git checkout [< tree-ish >] [--] < paths >

Wie pro Config jede vorhandene Version einer Datei spec (Pfade) in die worktree geladen werden. Zitat von Git-Checkout-docs:

Die folgende Sequenz überprüft die Master verzweigen, kehrt das Makefile zu zwei Revisionen zurück, löscht hello.c durch Fehler, und wird es wieder aus dem Index: 

$ git checkout master             
$ git checkout master~2 Makefile             
$ rm -f hello.c            
$ git checkout hello.c

Clearcase, ohne Multi-Site, ist ein einziges Repository aber Git verteilt wird. Clearcase verpflichtet auf Dateiebene, aber Git begeht im Repository-Ebene. (Dieser letzte Unterschied bedeutet, dass die ursprüngliche Frage auf einem Missverständnis beruht, wie hier in den anderen Beiträgen hingewiesen.)

Wenn das sind die Unterschiede wir reden dann denke ich, ‚linear‘ im Vergleich zu ‚DAG‘ eine verwirrende Art und Weise ist es, diese SCM-Systeme zu unterscheiden. In Clear all Versionen für eine Datei als die Dateiversion „Baum“ genannt, aber eigentlich ist es ein gerichteter azyklischer Graph! Der wirkliche Unterschied zu Git ist, dass Clear der DAGs pro Datei existieren. Also ich denke, es ist irreführend zu Clearcase als nicht-DAG und Git als DAG beziehen.

(BTW Versionen Clear seine Verzeichnisse in ähnlicher Weise auf seine Dateien -. Aber das ist eine andere Geschichte)

Ich bin mir nicht sicher, ob Sie etwas fragen, aber Sie zeigen, dass Accurev Streams sind verschiedene Werkzeuge als Git (oder SVN) Zweige. (Ich weiß nicht wissen, Clearcase).

Zum Beispiel mit Accurev Sie sind gezwungen , wie Sie sagen, bestimmte Abläufe zu verwenden, mit dem Sie eine überprüfbare Geschichte der Änderungen gibt, die nicht in Git unterstützt wird. Accurev Erbe macht bestimmte Arbeitsabläufe effizienter und andere unmöglich.

Mit Git können Sie Sondierungs haben getrennte Codierung in lokalen repos oder in Funktion Filialen, die nicht sehr gut von Accurev unterstützt werden würde.

Verschiedene Werkzeuge für unterschiedliche Zwecke gut sind; ist es nützlich, zu fragen, was jeder gut ist für .

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top