it-swarm.com.de

Versionskontrolle von Clear vs VS Git

Wir verwenden multisite clearcase repository, und häufig müssen wir unser System zusammenführen und aufbauen. Diese Zusammenführung und Replikation dauert fast 3 Tage, um standortübergreifend verfügbar zu sein. Um effizienter zu sein, planen wir den Umstieg auf Git Versionskontrolle. Könnten Sie bitte auf den möglichen Nachteil hinweisen, den wir haben könnten, wenn wir von Clearcase zu Git wechseln?

29
Anant

@ zzz777: Ihre Frage wurde in einer so zentralen Ansicht von ClearCase gestellt, dass sie für Personen, die ClearCase noch nie verwendet haben, nicht verständlich war. Tatsächlich ist Git Lichtjahre voraus von ClearCase, es sind kommerzielle SCMs, die OSS-Systeme einholen müssen.

Ich habe sowohl mit ClearCase als auch mit git Erfahrung, und ich kann Ihnen sagen, dass die Funktion "Zusammenführung (fehl) suchen" von ClearCase ein Ergebnis des (grundlegend defekten) Designs ist, das auf Versionierungsdateien basiert. In git benötigen Sie jedoch kein derart primitives Werkzeug um den gemeinsam genutzten Zweig mit Ihrem privaten Zweig zu verbinden. ClearCase ist dateiorientiert und das Einchecken von Dateien ist dateibasiert. Aus diesem Grund benötigen Sie das Suchwerkzeug (Dateien) zum Zusammenführen. Git ist jedoch auf Festschreibungsbasis und das ist das richtige Modell, seitdem Sie ein Problem beheben oder eine Funktion implementieren Das gesamte Changeset oder nichts davon ist die einzige Option, die Sinn macht.

Git hat eine sehr mächtige Merge-Funktion, die das Richtige tut, und es gibt zwei Möglichkeiten, um das zu tun, was Sie verlangen (Aktualisieren Ihres privaten Zweigs, um den gemeinsam genutzten Zweig + Ihre Änderungen zu erhalten).

Am offensichtlichsten ist es, eine Zusammenführung durchzuführen. In Ihrer privaten Zweigstelle tun Sie dies einfach:

git merge sharedbranch

wenn es Konflikte gibt (wirklich viel seltener als in ClearCase), lösen Sie diese und

git commit

Und das ist es. Als Bonus gilt: Da git alle historischen Daten enthält, müssen Sie nicht unzählige Stunden verschwenden. Wenn Sie, wie in ClearCase, viele Dateien haben, ist die Zusammenführung rasant schnell, wenn ClearCase in einer dynamischen Ansicht eine Beim Zusammenführen von 10 Dateien wird git das Zusammenführen von 100 Dateien wahrscheinlich leicht beenden.

Die Verwendung von git merge bedeutet, dass Sie die Historie beibehalten und ob Ihre Historie vor der Zusammenführung so aussah:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

nach dem Zusammenführen wird es so aussehen:

o---1---2---3 (sharedbranch)
 \           \
  a---b---c---m (privatebranch)

Dadurch bleibt der Verlauf Ihrer Änderungen erhalten, und andere können Ihre Arbeit überprüfen.

Und denken Sie daran, dies sind KEINE Datei-Revisions-Historien. Dies ist der Baumprotokoll. Dies ist das einzige Protokoll, das sinnvoll ist, um gespeichert zu werden, auch wenn sich Zweige nur um 1 oder 2 Dateien unterscheiden. Der Zustand, den Sie beibehalten möchten, ist der Baum, nicht einer Datei.

Die zweite Option ist die Verwendung von rebase. Dies bedeutet, dass Sie den Eindruck haben, dass alle Ihre Änderungen mit dem neuesten Code auf dem gemeinsam genutzten Zweig vorgenommen wurden.

Der Befehl, den Sie verwenden (wieder, während Sie sich im privaten Zweig befinden):

git rebase sharedbranch

Der Verlaufsbaum ändert sich von:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

zu

o---1---2---3 (sharedbranch)
             \
              a'--b'--c' (privatebranch)

Wenn Sie git also etwas Zeit geben, um es zu verstehen, und ein wenig verwenden, werden Sie sehen, wie viel besser das git-Modell ist und wie kaputt das ClearCase-Modell ist.

Übrigens, das böse Zwillingsproblem in ClearCase existiert einfach nicht in git, da git keine Verzeichnisse verfolgt (glauben Sie mir, das brauchen Sie NICHT).

Wenn Sie jemals eine Konfigurationsspezifikation hatten, die mit mehreren Zweigen etwas komplizierter ist und Sie Dateien von einem Zweig zum anderen migriert haben, wissen Sie wahrscheinlich, wie wichtig die Reihenfolge der Regeln in der Konfigurationsspezifikation ist und wie frustrierend dies ist Siehe alte Versionen der Dateien, da die Konfigurationsspezifikation "falsch" ist. Dies geschieht in ClearCase aufgrund seines Basiskonzeptes, und diese Art von Mist kann natürlich nicht bei git passieren.

Abschließend hat git kein primitives Werkzeug wie "find merge", weil es es nicht braucht. Es hat ein überlegenes Modell und ein überragendes Zusammenführungsmodell, das tatsächlich funktioniert. Es ist blitzschnell im Vergleich zu ClearCase (statische CCRC-Ansicht oder dynamische Ansicht, wie Sie es nennen).

Die einzige Stelle, an der ClearCase über einen Edge verfügen könnte, ist die sofortige Aktualisierung der dynamischen Ansicht. Dies wird jedoch durch die Tatsache gemindert, dass Sie einen schnelleren git checkout-Zweig eingeben können, als Sie die Konfigurationsspezifikation aktualisieren.

40
eddyp

Probleme, die ich in einem professionellen Büro für gemischte Fähigkeiten hatte:

  1. Veränderliche Geschichte.
    Mit GIT können Sie einige wirklich dumme (und mächtige) Dinge tun. Dies kann zu Quellenverlust führen.
  2. Automatisches Zusammenführen.
    Dies ist die beste Eigenschaft von git. ABER, wir mussten die Entwicklung für eine Woche herunterfahren, um den fehlenden Quellcode zu finden. MSVS hat ein glückliches Problem mit zufällig wechselnden Zeilenenden. Wenn Sie nicht regelmäßig aus dem Repository ziehen, wird dies verwirrt und Änderungen gehen verloren.
  3. Push/Pull-Reihenfolge.
    Clearcase übernimmt die Datumsordnung und den Verlauf für Sie, aber git ignoriert es.
  4. Inszenierung.
    Clearcase (mindestens UCM) übernimmt für Sie die Filialwerbung und andere Dinge. Git nicht. Sie müssen dies sorgfältig handhaben.
  5. $ ID $
    Gibt es nicht für git. Die Versionsverfolgung von aktuellen Releases und die Problembehebung, da die Version der Quelldatei bekannt ist, muss manuell gehandhabt werden. (Ich bin nicht sicher, was Ihr Veröffentlichungsprozess ist).

Für Ihr endgültiges Code-Repository kann ich ein Release-Repository vorschlagen, entweder ein anderes Quellcodeverwaltungssystem oder ein separates Git-Repository, das verwaltet wird und nur Pulls akzeptiert.

Ich benutze derzeit Git für mein Soloprojekt und es geht mir gut. Aber in einem gemischten Haus mit verschiedenen Redakteuren würde ich vorsichtig sein. Sie können Ihren Fuß wirklich abblasen, ohne es mit Git zu wissen.

Ich habe auch nicht verwendet, hg oder bzr. Es kann sich lohnen, diese anzuschauen, da einige der Probleme verschwinden und sie über Funktionen verfügen, um einige der oben genannten Probleme zu mindern. 

Ich hoffe das hilft.

12
PAntoine

Ich habe sowohl mit Git als auch mit ClearCase gearbeitet, und sobald Sie lernen wie Sie Git und dann verwenden, den Wechsel vornehmen, werden Sie nie zurückschauen. Stellen Sie sicher, dass Sie Zeit haben, um Ihre Entwickler zu schulen - dies sollte Ihre oberste Priorität sein. Git ist ein völlig anderer Ansatz für SCM als ClearCase.

Einige Dinge zu beachten (mögliche Nachteile):

  1. Sie benötigen einen true Repo-Master, nicht nur jemanden, der die Quelle überwacht, sondern jemanden, der die tatsächliche Funktionsweise des SCM (nicht nur die Anzeige einer GUI) kennt und mit Ihrem Verzweigungsmodell umgehen kann (siehe # 2)
  2. Annahme/Entwicklung eines robusten Zweigmodells. Ein tolles Beispiel, und ich habe es verwendet: http://nvie.com/posts/a-successful-git-branching-model/
  3. Sie werden viel Zeit investieren müssen, um Ihren Entwicklern zu helfen, alles neu zu lernen, von dem Sie dachten, dass Sie es mit SCM wissen/wissen wollen.

Wenn Sie die drei oben genannten Probleme überwinden können, gibt es nur einen kleinen Nachteil (Nummer 3 ist der härteste.) Bei @PAntoine beziehen sich die meisten dieser Probleme auf das Training. Für # 1 müsste eine wirklich schlechte Entscheidung für den Verlust von Quellcode erforderlich sein . git reflog gibt Ihnen Zugriff auf jedes Commit für das Repo. Die einzige Möglichkeit, die Quelle zu zerstören, wäre git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git Prune und git gc, die nur vom Repo-Master gehandhabt werden sollten.

9
kmatheny

Wie ich in " Was sind die grundlegenden ClearCase-Konzepte, die jeder Entwickler wissen sollte " hat, könnte ClearCase einige "dezentrale" Funktionen mit seinen Repos für mehrere Standorte haben, aber es ist immer noch ein CVCS im Kern:

  • es hat eine starke Verbindung mit der Systembenutzer-ID (die in einem DVCS nicht relevant ist, wo es keinen eindeutigen referenziellen Benutzer gibt).

  • es verfügt über ein eindeutiges Repo zum Verwalten von Label- und Zweignamen (admin vob), während Sie in 15 verschiedenen Git-Repos problemlos einen 'test'-Zweig definieren können (außer Sie müssen wissen, wofür repo1/test relativ zu repos2/test steht).

  • außerdem wird die Definition eines Zusammenführungsworkflows über die (UCM) Stream-Hierarchie zentralisiert (Sie können visualisieren, wo Sie eine Arbeit von einem Stream zu einem anderen zusammenführen sollen).

  • Über UCM wird eine Definition der Teilmenge der Codes (Komponente) mit Abhängigkeitsmanagement vorgeschlagen. Git hat nur Submodule, ohne den Erkennungsmechanismus außer Kraft zu setzen.

  • es verwaltet jede Art von Dateien, auch große Binärdateien, während ein DVCS (jede Art von DVCS) besser nur Quellcode verwaltet.

Das Fazit (bei unserer Migration von ClearCase zu Git) ist, dass es eine Reihe von Umgestaltungen/Reorganisationen des Quellcodes gibt, um verwaltbare Git-Repositories zu erhalten.

9
VonC

Benötigen Sie ein Tool, das Sie bei Ihrem Software Configuration Management (SCM) oder Ihrer Versionskontrolle (System) (VCS) unterstützt?

Darauf läuft die Diskussion zwischen ClearCase und Git hinaus.

Sie vergleichen also Äpfel mit Orangen.

Wenn Sie sich ClearCase als nur ein weiteres VCS vorstellen, haben Sie eine genaue Vorstellung davon, was ClearCase ist. Bleiben Sie bei ClearCase, wenn Sie das richtige Produkt aus Ihrem Shop versenden möchten. 

Andererseits ist Git in diesem Moment wahrscheinlich das beste VCS auf dem Markt (obwohl es keine SCM-Unterstützung bietet), also wechseln Sie zu ihm, wenn es sich bei Ihrem Anliegen um Verzweigungen und Zusammenführen handelt ... (eine Seite beachtet die Zusammenführungskonflikte.) sind das Ergebnis einer schlecht gesetzten Basislinie und nicht ordnungsgemäß konfigurierten Ansichten) ... VOB Replikation ist scheiße - das gebe ich Ihnen. 

Der Nachteil Ihres geplanten Umzugs besteht darin, dass Sie Ihre Unterstützung für SCM-Werkzeuge wegwerfen. Sie müssen sich einer Vielzahl anderer Tools und einer Menge Handarbeit stellen, um das zu erreichen, was Sie mit ClearCase aus der Box hatten.

Auf jeden Fall ist ein gutes VCS das Rückgrat eines jeden SCM, so dass sich Ihre Umstellung auf Git langfristig auszahlt. 

0
Legna