dvcs - ist "Clone to Branch" ein gängiger Workflow?

Ich habe kürzlich mit einem Kollegen über dvcs gesprochen, weil unser Büro anfängt, über einen Wechsel von TFS nachzudenken (wir sind ein MS-Shop). Dabei war ich sehr verwirrt, weil er sagte, dass er, obwohl er Mercurial verwendet, noch nichts von einem "Branch" - oder "Checkout" -Befehl gehört habe und diese Begriffe ihm unbekannt waren. Nachdem er sich gefragt hatte, wie es möglich war, dass er nichts über sie wusste und erklärte, wie dvcs-Zweige in Ihren lokalen Dateien "an Ort und Stelle" funktionieren, war er ziemlich verwirrt.

Er erklärte, dass er, ähnlich wie TFS, wenn er einen "Zweig" erstellen möchte, dies durch Klonen tut, sodass er eine vollständige Kopie seines Repos hat. Das kam mir wirklich seltsam vor, aber der Vorteil, den ich zugeben muss, ist, dass Sie zwei Zweige gleichzeitig betrachten oder bearbeiten können, da die Dateien getrennt sind.

Bei der Suche auf dieser Website, um festzustellen, ob dies gefragt wurde, bevor ich einen Kommentar sah, dass viele Online-Ressourcen diese "Clone to Branch" -Methode zum Entsetzen des Posters fördern. Ist das in der dvcs-Community tatsächlich üblich? Und was sind einige der Vor- und Nachteile dieses Weges? Ich würde es niemals tun, da ich nicht mehrere Zweige gleichzeitig sehen muss, das Umschalten schnell ist und nicht alle Klone meine Festplatte füllen müssen.

Abgesehen von dem allgemeinen Vorteil / Nachteil, beide Zweige sehen zu können, gibt es meiner Meinung nach einen Mercurial-spezifischen Vorteil.

Wenn Sie klonen, um einen Zweig zu erstellen, können Sie den Klon später löschen, wenn Sie Ihre Änderungen nicht beibehalten möchten. Wenn Sie sich entscheiden, sie zusammenzuführen, ist die Tatsache, dass Sie beschlossen haben, Ihre Änderungen auf diese Weise zu trennen, für niemanden sichtbar.

Wenn Sie dagegen hg brancheinen neuen benannten Zweig erstellen, wird der Zweigname beim Festschreiben im Verlauf aufgezeichnet, ist für alle anderen sichtbar und muss ziemlich eindeutig sein, um spätere Verwechslungen zu vermeiden. Dies ist möglicherweise nicht geeignet, wenn Ihr Zweig für die Entwicklung einer experimentellen Funktion oder für eine Änderung vorgesehen ist, die sich als klein herausstellen könnte.

Wenn Sie benannte Zweige verwenden, um freigegebene Versionen Ihrer Software zu verwalten und sie auch zum Entwickeln kurzfristiger Funktionen oder Bugfixes zu verwenden, kann es leicht zu Verwirrung kommen, da es (außer Namenskonventionen) keine Möglichkeit gibt, diese beiden Arten von Zweigen getrennt zu halten.

http://mercurial.selenic.com/wiki/StandardBranching erklärt dies ausführlicher. Erwähnenswert ist auch, dass es seit Mercurial 1.8 möglich ist, ein Lesezeichen ( hg bookmark) zu erstellen - einen verfügbaren Namen für einen kurzlebigen Zweig. Lesezeichen können verschoben, gezogen, verschoben und gelöscht werden.

Jedes Mal, wenn Sie ein Commit in einem DVCS durchführen, erstellen Sie technisch einen Zweig in der Historie. Jedes Mal, wenn Sie ihn in das gesegnete Repository zurückschieben, integrieren Sie ihn wieder. Hier kommt der interessante Teil:

• Wenn während Ihres Commits niemand eine Änderung vorgenommen hat, sieht es nicht wie ein Zweig in der DAG aus (gerichteter azyklischer Graph).
• Wenn jemand anderes während Ihres Commits eine Änderung vorgenommen hat, sieht diese wie ein Zweig in der DAG aus, der nur unbenannt ist

Denken Sie daran, dass die Schaltfläche "Gabel" in Bitbucket / github? Das Verzweigen als Synonym für Verzweigung angesehen werden kann. Die Schaltfläche "Gabel" ist nur ein Klon dieses Repositorys für Ihr Konto.

Der einzige Vorteil des "Klonens in einen Zweig" besteht darin, dass Sie an zwei Punkten in der Geschichte gleichzeitig arbeiten können. Ironischerweise ist dies für Ihren Mitarbeiter ein gängiger Workflow, um gleichzeitig an verschiedenen Zweigen zu arbeiten (ohne hin und her gehen zu müssen) ).

Sagen Sie Ihrem Kollegen, er soll lernen, wie man verzweigt . Es ist sehr einfach. Hier finden Sie ein Tutorial:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

"In Zweig verzweigen" ist sinnvoll, wenn Sie gleichzeitig in verschiedenen Zweigen arbeiten oder wenn Sie ein Experiment ausprobieren möchten, ohne einen permanenten Zweig im Verlauf zu erstellen, und ihn dennoch wieder in einen bereits vorhandenen Zweig integrieren können .

Ich persönlich mag diese Praxis nicht und bevorzuge es, Filialen zu machen und sie bei Bedarf zu schließen. Hier ist, wie Sie es tun:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Hoffe, dies beseitigt Ihre Zweifel an der DVCS-Verzweigung, hier sind Verzweigungen nicht mehr beängstigend.

Ich würde mir persönlich keine Sorgen machen, dass Code meine Festplatte füllt ... Erstens ist es nur Code, und zweitens werden Sie nicht alle Ihre Klone für immer behalten.

Diese Methode wird in vielen Online-Ressourcen, insbesondere für Hg, beworben. Ich habe noch nie gesehen, dass es in der Produktion verwendet wird. In CI-Umgebungen ist es viel häufiger, kurzlebige Feature-Zweige zu haben als zusätzliche Repository-Klone. Ich sehe keinen Vorteil darin, wenn irgendetwas Ihre Geschichte verwirrender macht, nicht weniger, und es bringt Ihnen auch nichts. Wenn Sie Ihren neuen Code neben dem alten Code anzeigen möchten, können Sie mit einem Diff / Merge-Tool die beiden Commits nebeneinander anzeigen. Der zusätzliche Vorteil besteht darin, dass Ihre Änderungen hervorgehoben werden.