Ich komme aus einem ClearCase-Hintergrund, wo wir (vereinfacht gesagt) einen Workflow hatten, der aus drei Schritten bestand, bei denen der Stamm ganz links instabil war, der Stamm in der Mitte die Qualitätssicherung war und der Stamm ganz rechts stabil war. dh)
A A A
| | |
B C |
"https://stackoverflow.com/" |
C | E
| | /
D E
| /
E
Wie Sie sehen können, enthält der Stable-Trunk nur die qualifizierten Versionen. Ich habe Probleme beim Replizieren dieses Workflows in Git, da die Versionen B, C und D auch in den QA-Trunk und anschließend in den Stable-Trunk gepusht werden. In meinen Augen widerspricht dies dem Zweck eines “sauberen” Stammes, der nur stabile Versionen enthält.
Nun, es gibt offensichtlich grundlegende Unterschiede zwischen Git und ClearCase, was sicherlich erklärt, warum ich Probleme habe, meine früheren Konzepte zu verwenden, um einen Workflow zu spezifizieren.
Ich versuche seit ein paar Tagen, mich mit diesen neuen SCM-Tools vertraut zu machen (ich habe mir auch Mercurial angesehen). könnte wirklich ein paar Hinweise gebrauchen, wie es weitergehen soll. Wir entwickeln auf Mac- und Windows-PCs und die überwiegende Mehrheit der Teams bevorzugt GUI-Tools gegenüber der Befehlszeile.
Vielen Dank! 🙂
Zuerst können Sie diesen Vergleich zwischen ClearCase und Git lesen
Wie in Mittelweg zwischen Submodulen und Zweigen erklärt, ist das einzige Konzept, das Sie wahrscheinlich täuschen wird, wenn Sie von ClearCase kommen, der Begriff der Komposition (Konfigurationsvererbung): siehe Flexible vs. statische Verzweigung (GIT vs. Clearcase/Accurev).
ClearCase arbeitet Datei für Datei (oder Aktivität für Aktivität, wobei jede Aktivität eine Gruppe von Dateien ist).
Git arbeitet Blob-Delta für Blob-Delta (jeder Blob repräsentiert eine Inhalt: wenn zwei Dateien den gleichen Inhalt haben, wird nur ein “Blob” gespeichert)
Das bedeutet, dass das, was Sie in ClearCase durch Verzweigungen/Streams und Aktivitäten zu tun versuchen (wenn Sie UCM verwenden), mit größerer Wahrscheinlichkeit erreicht wird durch:
- Commit-Neuordnung (rebase –interactive, was der “git”-Weg ist und in Mercurial nicht empfohlen wird)
- und/oder Veröffentlichung (Dies ist eine orthogonale Dimension zur Verzweigung, spezifisch für DVCS)
neu ordnen + zusammenführen (nur für Commits, die noch nicht “veröffentlicht”, dh nicht gepusht wurden):
Sie ordnen die auf Ihren Code angewendeten Änderungsdeltas neu an, um nur das zusammenzuführen, was Sie möchten.
trunk => trunk' QA => QA' stable
A B'
| |
B D'
| |
C A'----A' C''
| | | |
D C' C' A''-- A'' (--: merge to branch)
| | | | |
E E E E E
- Nachbestellung + Veröffentlichung (drücken):
Sie können jede Code-Promotion auch durch ein eigenes Git-Repo darstellen.
Sobald die Commits in der richtigen Reihenfolge sind, pushen Sie die relevanten Branches in ein QA-Repo oder ein stabiles Repo.
Die Neuordnung (Umschreiben der Geschichte) ist:
Siehe auch:
