it-swarm.dev

Ich bin ein Subversion-Geek. Warum sollte ich Mercurial oder Git oder ein anderes DVCS in Betracht ziehen oder nicht?

Ich versuche die Vorteile des verteilten Versionskontrollsystems (DVCS) zu verstehen.

Ich fand Subversion Re-Education und dieser Artikel von Martin Fowler sehr nützlich.

Mercurial und andere DVCS fördern eine neue Art der Codebearbeitung mit Änderungssätzen und lokalen Commits. Es verhindert, dass die Hölle und andere Probleme der Zusammenarbeit zusammengeführt werden

Wir sind davon nicht betroffen, da ich kontinuierliche Integration übe und allein in einer privaten Niederlassung zu arbeiten, ist keine Option, es sei denn, wir experimentieren. Wir verwenden für jede Hauptversion einen Zweig, in dem wir Fehler beheben, die aus dem Trunk zusammengeführt wurden.

Mit Mercurial können Sie Leutnants haben

Ich verstehe, dass dies für sehr große Projekte wie Linux nützlich sein kann, aber ich sehe den Wert in kleinen und sehr kooperativen Teams (5 bis 7 Personen) nicht.

Mercurial ist schneller, benötigt weniger Speicherplatz und die vollständige lokale Kopie ermöglicht schnellere Protokollierungs- und Differenzierungsvorgänge.

Das macht mir auch nichts aus, da ich selbst bei sehr großen Projekten, an denen ich arbeite, keine Geschwindigkeits- oder Platzprobleme mit SVN bemerkte.

Ich suche nach Ihren persönlichen Erfahrungen und/oder Meinungen von ehemaligen SVN-Freaks. Besonders in Bezug auf das Changesets Konzept und die insgesamt Leistung Boost, die Sie gemessen haben.

UPDATE (12. Januar): Ich bin jetzt überzeugt, dass es einen Versuch wert ist.

UPDATE (12. Juni): Ich habe Mercurial geküsst und es hat mir gefallen. Der Geschmack seiner Kirsche verpflichtet sich. Ich küsste Mercurial, nur um es zu versuchen. Ich hoffe, mein SVN-Server hat nichts dagegen. Es fühlte sich so falsch an. Es fühlte sich so richtig an. Das heißt nicht, dass ich heute Abend verliebt bin.

FINAL UPDATE (29. Juli): Ich hatte das Privileg, Eric Sink 's nächstes Buch mit dem Titel Versionskontrolle durch Beispiel zu rezensieren. Er beendete mich zu überzeugen. Ich werde für Mercurial gehen.

304
user2567

Hinweis: Siehe "EDIT" für die Antwort auf die aktuelle Frage


Lesen Sie zunächst Subversion Re-Education von Joel Spolsky. Ich denke, die meisten Ihrer Fragen werden dort beantwortet.

Eine weitere Empfehlung, Linus Torvalds 'Vortrag auf Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Dieser andere könnte auch die meisten Ihrer Fragen beantworten, und es ist ziemlich unterhaltsam.

Übrigens, etwas, das ich ziemlich lustig finde: Sogar Brian Fitzpatrick & Ben Collins-Sussman, zwei der ursprünglichen Schöpfer von Subversion, sagten in einem Google-Talk "Entschuldigung", dass Subversion Mercurial (und DVCSs im Allgemeinen) unterlegen sei.

Jetzt, IMO und im Allgemeinen, entwickelt sich die Teamdynamik mit jedem DVCS natürlicher. Ein herausragender Vorteil ist, dass Sie sich offline verpflichten können, da dies Folgendes impliziert:

  • Sie sind nicht auf einen Server und eine Verbindung angewiesen, was schnellere Zeiten bedeutet.
  • Nicht Sklave von Orten zu sein, an denen Sie einen Internetzugang (oder ein VPN) erhalten können, nur um sich festlegen zu können.
  • Jeder hat eine Sicherungskopie von allem (Dateien, Verlauf), nicht nur vom Server. Das heißt, jeder kann zum Server werden .
  • Sie können zwanghaft festschreiben, wenn Sie müssen, ohne den Code anderer zu verfälschen . Commits sind lokal. Sie treten sich beim Begehen nicht gegenseitig auf die Zehen. Sie brechen die Builds oder Umgebungen anderer nicht nur durch Festschreiben.
  • Personen ohne "Festschreibungszugriff" können Festschreibungen vornehmen (da das Festschreiben in einem DVCS nicht das Hochladen von Code bedeutet), wodurch die Barriere für Beiträge gesenkt wird. Sie können entscheiden, ob Sie ihre Änderungen übernehmen möchten oder nicht.
  • Es kann die natürliche Kommunikation verstärken, da ein DVCS dies wesentlich macht ... in Subversion haben Sie stattdessen Rennen, die die Kommunikation erzwingen, aber Ihre Arbeit behindern.
  • Mitwirkende können sich zusammenschließen und ihre eigene Zusammenführung durchführen, was letztendlich weniger Arbeit für Integratoren bedeutet.
  • Mitwirkende können ihre eigenen Niederlassungen haben, ohne die anderer zu beeinflussen (sie können sie jedoch bei Bedarf teilen).

Über Ihre Punkte:

  • Die Verschmelzung der Hölle gibt es in DVCSland nicht. muss nicht behandelt werden. Siehe nächster Punkt .
  • In DVCSs repräsentiert jeder einen "Zweig", was bedeutet, dass jedes Mal, wenn Änderungen vorgenommen werden, Zusammenführungen stattfinden. Benannte Zweige sind eine andere Sache.
  • Sie können die kontinuierliche Integration weiterhin verwenden, wenn Sie möchten. IMHO nicht notwendig, warum Komplexität hinzufügen? Halten Sie Ihre Tests einfach als Teil Ihrer Kultur/Politik.
  • Mercurial ist in einigen Dingen schneller, Git ist in anderen Dingen schneller. Nicht wirklich bis zu DVCSs im Allgemeinen, aber zu ihren speziellen Implementierungen AFAIK.
  • Jeder wird immer das vollständige Projekt haben, nicht nur Sie. Die verteilte Sache hat damit zu tun, dass Sie lokal festschreiben/aktualisieren können. Das Teilen/Nehmen von außerhalb Ihres Computers wird als Drücken/Ziehen bezeichnet.
  • Lesen Sie erneut Subversion Re-Education. DVCSs sind einfacher und natürlicher, aber sie unterscheiden sich. Versuchen Sie nicht zu glauben, dass cvs/svn === Basis aller Versionsverwaltung ist.

Ich habe einige Dokumentationen zum Joomla-Projekt beigetragen, um eine Migration zu DVCS zu predigen, und hier Ich habe einige Diagramme erstellt, um zentralisierte und verteilte Diagramme zu veranschaulichen.

Zentralisiert

alt text

In der allgemeinen Praxis verteilt

alt text

In vollem Umfang verteilt

alt text

Sie sehen im Diagramm, dass es immer noch ein "zentrales Repository" gibt, und dies ist eines der Lieblingsargumente der Fans der zentralen Versionierung: "Sie werden immer noch zentralisiert", und nein, das sind Sie nicht, da das "zentralisierte" Repository nur Sie sind Alle sind sich einig (z. B. ein offizielles Github-Repo), dies kann sich jedoch jederzeit ändern.

Dies ist der typische Workflow für Open-Source-Projekte (z. B. ein Projekt mit massiver Zusammenarbeit) unter Verwendung von DVCSs:

alt text

Bitbucket.org ist eine Art Github-Äquivalent für Mercurial. Wissen Sie, dass es unbegrenzte private Repositories mit unbegrenztem Speicherplatz gibt. Wenn Ihr Team kleiner als fünf ist, können Sie es kostenlos verwenden.

Der beste Weg, sich von der Verwendung eines DVCS zu überzeugen, ist das Ausprobieren eines DVCS. Jeder erfahrene DVCS-Entwickler, der svn/cvs verwendet hat, wird Ihnen sagen, dass es sich lohnt und dass er nicht weiß, wie er seine ganze Zeit ohne DVCS überlebt hat.


[~ # ~] edit [~ # ~] : Um Ihre zweite Bearbeitung zu beantworten, kann ich nur wiederholen, dass Sie mit einem DVCS einen anderen Workflow haben, ich Ich würde Ihnen raten, nicht nach Gründen zu suchen, um es wegen Best Practices nicht zu versuchen. Es fühlt sich so an, als würden Leute argumentieren, dass OOP nicht notwendig ist, weil sie es können Umgehen Sie komplexe Entwurfsmuster mit dem, was sie immer mit dem Paradigma XYZ tun. Sie können trotzdem davon profitieren.

Probieren Sie es aus, Sie werden sehen, wie die Arbeit in einer "privaten Niederlassung" tatsächlich eine bessere Option ist. Ein Grund, warum ich sagen kann, warum das Letzte wahr ist, ist, dass Sie die Angst vor einem Commit verlieren , sodass Sie jederzeit ein Commit durchführen können, wenn Sie es für richtig halten und arbeiten ein natürlicherer Weg.

In Bezug auf "Hölle verschmelzen" sagen Sie "es sei denn, wir experimentieren", ich sage "auch wenn Sie experimentieren + warten + gleichzeitig in überarbeiteter Version 2.0 arbeiten ". Wie ich bereits sagte, gibt es keine Verschmelzung der Hölle, weil:

  • Jedes Mal, wenn Sie sich verpflichten, generieren Sie einen unbenannten Zweig, und jedes Mal, wenn Ihre Änderungen den Änderungen anderer Personen entsprechen, erfolgt eine natürliche Zusammenführung.
  • Da DVCSs für jedes Commit mehr Metadaten erfassen, treten beim Zusammenführen weniger Konflikte auf. Sie können es also sogar als "intelligentes Zusammenführen" bezeichnen.
  • Wenn Sie auf Zusammenführungskonflikte stoßen, können Sie Folgendes verwenden:

alt text

Außerdem spielt die Projektgröße keine Rolle. Als ich von Subversion wechselte, sah ich bereits die Vorteile, wenn ich alleine arbeitete. Alles fühlte sich einfach richtig an. Mit den Änderungssätzen (nicht genau eine Revision, sondern eine bestimmte Reihe von Änderungen für bestimmte Dateien, für die Sie ein Commit einschließen, isoliert vom Status der Codebasis) können Sie Visualisieren Sie genau, was Sie damit gemeint haben, was Sie mit einer bestimmten Gruppe von Dateien gemacht haben, nicht mit der gesamten Codebasis.

In Bezug auf die Funktionsweise von Änderungssätzen und die Leistungssteigerung. Ich werde versuchen, es mit einem Beispiel zu veranschaulichen, das ich gerne geben möchte: Der Mootools-Projektwechsel von svn ist in ihrem Github-Netzwerkdiagramm dargestellt.

Vorher

alt text

Nach

alt text

Was Sie sehen, ist, dass Entwickler sich beim Festschreiben auf ihre eigene Arbeit konzentrieren können, ohne befürchten zu müssen, den Code anderer zu beschädigen. Sie sorgen sich darum, den Code anderer nach dem Drücken/Ziehen zu brechen (DVCSs: zuerst festschreiben, dann drücken/ziehen, dann aktualisieren) ), aber da das Zusammenführen hier klüger ist, tun sie es oft nie ... selbst wenn es einen Zusammenführungskonflikt gibt (was selten vorkommt), verbringen Sie nur 5 Minuten oder weniger damit, ihn zu beheben.

Ich empfehle Ihnen, jemanden zu suchen, der weiß, wie man Mercurial/git verwendet, und ihn/sie zu bitten, es Ihnen praktisch zu erklären. Indem ich ungefähr eine halbe Stunde mit einigen Freunden in der Befehlszeile verbracht habe, während ich Mercurial mit unseren Desktops und Bitbucket-Konten verwendet habe, um ihnen das Zusammenführen zu zeigen, und sogar Konflikte erfunden habe, um zu sehen, wie sie in einer lächerlichen Zeitspanne behoben werden können, konnte ich zeigen ihnen die wahre Kraft eines DVCS.

Schließlich würde ich Ihnen empfehlen, Mercurial + Bitbucket anstelle von Git + Github zu verwenden, wenn Sie mit Windows-Leuten arbeiten. Mercurial ist auch ein bisschen einfacher, aber Git ist leistungsfähiger für eine komplexere Repository-Verwaltung (z. B. Git Rebase ).

Einige zusätzliche empfohlene Messwerte:

333
dukeofgaming

Was Sie sagen, ist unter anderem, dass Sie keine verteilte Versionskontrolle benötigen, wenn Sie im Wesentlichen in einem einzelnen Zweig bleiben.

Das ist wahr, aber ist es nicht eine unnötig starke Einschränkung Ihrer Arbeitsweise und eine, die sich nicht gut auf mehrere Standorte in mehreren Zeitzonen skalieren lässt? Wo sollte sich der zentrale Subversion-Server befinden und sollte jeder nach Hause gehen, wenn dieser Server aus irgendeinem Grund nicht verfügbar ist?

DVCSes sind zu Subversion, was Bittorrent zu FTP ist

(technisch nicht legal). Wenn Sie darüber nachdenken, werden Sie vielleicht verstehen, warum es so ein großer Sprung nach vorne ist?

Für mich führte unser Wechsel zu Git sofort dazu

  • Unsere Backups sind einfacher durchzuführen (nur "Git Remote Update" und fertig)
  • Es ist einfacher, kleine Schritte auszuführen, wenn Sie ohne Zugriff auf das zentrale Repository arbeiten. Sie arbeiten einfach und synchronisieren, wenn Sie zu dem Netzwerk zurückkehren, in dem sich das zentrale Repository befindet.
  • Schneller Hudson baut. Git Pull viel schneller zu verwenden als zu aktualisieren.

Überlegen Sie also, warum Bittorrent besser ist als FTP, und überdenken Sie Ihre Position :)


Hinweis: Es wurde erwähnt, dass es Anwendungsfälle gibt, in denen FTP schneller und bittorrenter ist. Dies gilt genauso wie die Sicherungsdatei, die Ihr Lieblingseditor verwaltet, schneller zu verwenden ist als ein Versionskontrollsystem.

59
user1249

Das Killer-Feature verteilter Versionskontrollsysteme ist der verteilte Teil. Sie checken keine "Arbeitskopie" aus dem Repository aus, sondern klonen eine gesamte Kopie des Repositorys. Dies ist enorm, da es leistungsstarke Vorteile bietet:

  • Sie können die Vorteile der Versionskontrolle nutzen, auch wenn Sie keinen Internetzugang haben, wie z. Dieser ist leider überbeansprucht und überhyped, weil DVCS großartig ist - es ist einfach kein starkes Verkaufsargument, da viele von uns ungefähr so ​​oft ohne Internetzugang codieren, wie es anfängt, Frösche zu regnen.

  • Der wahre Grund, warum ein lokales Repository ein Killer ist, ist, dass Sie haben die vollständige Kontrolle über Ihren Commit-Verlauf, bevor er in das Master-Repository verschoben wird.

Schon mal einen Fehler behoben und am Ende so etwas wie:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Und so weiter. Ein solcher Verlauf ist chaotisch - es gab wirklich nur einen Fix, aber jetzt ist die Implementierung auf viele Commits verteilt, die unerwünschte Artefakte wie das Hinzufügen und Entfernen von Debugging-Anweisungen enthalten. Bei einem System wie SVN besteht die Alternative darin, nicht (!!!) festzuschreiben, bis alles funktioniert, um den Verlauf sauber zu halten. Selbst dann vergehen Fehler und Murphys Gesetz wartet darauf, Sie zu brutalisieren, wenn erhebliche Mengen an Arbeit nicht durch die Versionskontrolle geschützt sind.

Wenn Sie einen lokalen Klon des Repositorys haben, den Sie besitzen , wird dies behoben, da Sie den Verlauf neu schreiben können, indem Sie kontinuierlich "fix it" und "oops" rollen "Commits in das Commit" Bugfix ". Am Ende des Tages wird ein sauberes Commit an das Master-Repository gesendet, das wie folgt aussieht:

r321 Fixed annoying bug.

So sollte es sein.

Die Möglichkeit, den Verlauf neu zu schreiben, ist in Kombination mit dem Verzweigungsmodell noch leistungsfähiger. Ein Entwickler kann Arbeiten ausführen, die innerhalb eines Zweigs vollständig isoliert sind. Wenn es dann an der Zeit ist, diesen Zweig in den Trunk zu bringen, haben Sie alle möglichen interessanten Optionen:

  • Führen Sie eine einfache Vanille-Zusammenführung durch . Bringt alles in Warzen und alles.

  • Führen Sie eine Rebase durch . Ermöglicht es Ihnen, den Zweigverlauf zu sortieren, die Reihenfolge der Commits neu zu ordnen, Commits zu verwerfen, Commits zusammenzufügen, Commit-Nachrichten neu zu schreiben - sogar Commits zu bearbeiten oder neue hinzuzufügen! Ein verteiltes Versionskontrollsystem unterstützt die Codeüberprüfung umfassend.

Nachdem ich erfahren hatte, wie lokale Repositories es mir ermöglichten, meine Geschichte zu bearbeiten, um die Vernunft meiner Programmierkollegen und meines zukünftigen Selbst zu gewährleisten, legte ich SVN endgültig auf. Mein Subversion-Client ist jetzt git svn.

Das Ermöglichen, dass Entwickler und Manager die redaktionelle Kontrolle über den Commit-Verlauf ausüben, führt zu einem besseren Projektverlauf, und ein sauberer Verlauf, mit dem ich arbeiten kann, hilft meiner Produktivität als Programmierer wirklich. Machen Sie sich keine Sorgen, wenn Ihnen all das Gerede über das "Umschreiben des Verlaufs" Angst macht, denn dafür sind zentrale, öffentliche oder Master-Repositorys gedacht. Der Verlauf kann (und sollte!) Bis zu dem Punkt neu geschrieben werden, an dem jemand ihn in einen Zweig in einem Repository bringt, aus dem andere Personen ziehen. Zu diesem Zeitpunkt sollte die Geschichte wie auf einer Steintafel geschnitzt behandelt werden.

46
Sharpie

die Antwort von dukofgamings ist wahrscheinlich so gut wie es nur geht, aber ich möchte dies aus einer anderen Richtung angehen.

Nehmen wir an, dass das, was Sie sagen, absolut wahr ist und dass Sie durch die Anwendung bewährter Verfahren die Probleme vermeiden können, die mit DVCS behoben werden sollen. Bedeutet dies, dass ein DVCS Ihnen keinen Vorteil bietet? Menschen stinken bei der Befolgung von Best Practices. Die Leute sind gehen um es zu vermasseln. Warum sollten Sie also die Software vermeiden, mit der eine Reihe von Problemen behoben werden sollen, und sich stattdessen darauf verlassen, dass die Mitarbeiter etwas tun, das Sie im Voraus vorhersagen können, dass sie es nicht tun werden?

18
philosodad

Ja, es tut weh, wenn Sie große Commits in Subversion zusammenführen müssen. Dies ist aber auch eine großartige Lernerfahrung, bei der Sie alles tun, um Konflikte zu vermeiden. Mit anderen Worten, Sie lernen häufig einchecken . Eine frühzeitige Integration ist eine sehr gute Sache für jedes Projekt am selben Ort. Solange alle das tun, sollte die Verwendung von Subversion kein großes Problem sein.

Git zum Beispiel war entworfen für verteilte Arbeit und ermutigt Leute, an ihren eigenen Projekten zu arbeiten und eigene Gabeln für eine (eventuelle) spätere Zusammenführung zu erstellen. Es war nicht speziell für die kontinuierliche Integration in ein "kleines und sehr kooperatives Team" konzipiert, was das OP verlangt. Es ist eher das Gegenteil, denken Sie daran. Sie werden die ausgefallenen verteilten Funktionen nicht nutzen können, wenn Sie nur im selben Raum sitzen und gemeinsam am selben Code arbeiten.

Für ein Team, das sich am selben Ort befindet und CI verwendet, denke ich wirklich nicht, dass es wichtig ist, ob Sie ein verteiltes System verwenden oder nicht. Es kommt auf Geschmack und Erfahrung an.

9
Martin Wickman

Weil Sie Ihr eigenes Wissen ständig herausfordern sollten. Sie lieben Subversion, und ich kann verstehen, dass ich es viele Jahre lang verwendet habe und mich sehr darüber gefreut habe, aber das bedeutet nicht, dass es immer noch das Werkzeug ist, das am besten zu Ihnen passt.

Ich glaube, als ich anfing, es zu benutzen, war es zu dieser Zeit die beste Wahl. Aber im Laufe der Zeit tauchen andere Tools auf, und jetzt bevorzuge ich Git, auch für meine eigenen Freizeitprojekte.

Und Subversion hat einige Mängel. Z.B. Wenn Sie ein Verzeichnis auf der Disc umbenennen, wird es im Repository nicht umbenannt. Das Verschieben von Dateien wird nicht unterstützt, sodass das Verschieben von Dateien ein Kopier-/Löschvorgang ist und das Zusammenführen von Änderungen beim Verschieben/Umbenennen von Dateien schwierig wird. Das Merge-Tracking ist nicht wirklich in das System integriert, sondern wird in Form einer Problemumgehung implementiert.

Git löst diese Probleme (einschließlich der automatischen Erkennung, ob eine Datei verschoben wurde, müssen Sie nicht einmal mitteilen, dass dies eine Tatsache ist).

Auf der anderen Seite können Sie mit git nicht wie Subversion auf einzelnen Verzeichnisebenen verzweigen.

Meine Antwort lautet also: Sie sollten nach Alternativen suchen, prüfen, ob sie Ihren Anforderungen besser entsprechen als Sie es kennen, und dann entscheiden.

8
Pete

In Bezug auf die Leistung hat Git oder ein anderes DVCS einen großen Vorteil gegenüber SVN, wenn Sie von einem Zweig zu einem anderen wechseln oder von einer Revision zu einer anderen springen müssen. Da alles lokal gespeichert ist, sind die Dinge viel schneller als bei SVN.

Das allein könnte mich zum Wechseln bringen!

7
Xavier Nodet

Anstatt an der Idee festzuhalten, dass "durch Anwenden von Best Practices kein DVCS erforderlich ist", sollten Sie berücksichtigen, dass der SVN-Workflow ein Workflow mit einer Reihe von Best Practices und der GIT/Hg-Workflow ein anderer Workflow ist. mit einem anderen Satz von Best Practices.

git bisect (Und alle Auswirkungen auf Ihr Haupt-Repository)

In Git ist ein sehr wichtiges Prinzip, dass Sie Fehler mit git bisect Finden können. Dazu nehmen Sie die letzte Version, von der bekannt ist, dass sie funktioniert, und die erste Version, von der bekannt ist, dass sie fehlschlägt, und führen (mit Hilfe von Git) eine binäre Suche durch, um herauszufinden, welches Commit den Fehler verursacht hat. Dazu muss Ihr gesamter Revisionsverlauf relativ frei von anderen Fehlern sein, die Ihre Fehlersuche beeinträchtigen können (ob Sie es glauben oder nicht, dies funktioniert in der Praxis ziemlich gut, und Linux-Kernel-Entwickler tun dies die ganze Zeit).

Um die Fähigkeit git bisect Zu erreichen, entwickeln Sie einen neuen Feature-eigenen Feature-Zweig , bauen ihn neu auf und bereinigen den Verlauf (also ziehen Sie an Es sind keine nicht funktionierenden Revisionen in Ihrem Verlauf bekannt - nur eine Reihe von Änderungen, mit denen Sie das Problem teilweise beheben können. Wenn die Funktion fertig ist, fügen Sie sie in den Hauptzweig mit dem Arbeitsverlauf ein.

Damit dies funktioniert, müssen Sie außerdem diszipliniert sein, von welcher Version des Hauptzweigs aus Sie Ihren Feature-Zweig starten. Sie können nicht einfach vom aktuellen Status des Zweigs master ausgehen, da dies möglicherweise nicht verwandte Fehler aufweist. Daher wird in der Kernel-Community empfohlen, die Arbeit mit der neuesten stabilen Version des Kernels zu beginnen (für große Funktionen) ) oder um die Arbeit mit dem neuesten getaggten Release-Kandidaten zu beginnen.

Sie können Ihren Zwischenfortschritt auch sichern, indem Sie den Feature-Zweig in der Zwischenzeit auf einen Server übertragen. Sie können den Feature-Zweig auch auf einen Server übertragen, um ihn für andere Personen freizugeben und Feedback einzuholen, bevor die Funktion abgeschlossen ist, bevor Sie dies tun müssen Verwandeln Sie Code in eine permanente Funktion der Codebasis, mit der sich jeder * in Ihrem Projekt befassen muss.

Die Manpage gitworkflows ist eine gute Einführung in die Workflows, für die Git entwickelt wurde. Außerdem Warum Git besser ist als X beschreibt Git-Workflows.

Große, verteilte Projekte

Warum brauchen wir Leutnants in einem eng zusammenarbeitenden Team mit guten Praktiken und guten Designgewohnheiten?

Denn in Projekten wie Linux sind so viele Personen involviert, die so geografisch verteilt sind, dass es schwierig ist, so eng zusammenzuarbeiten wie ein kleines Team, das sich einen Konferenzraum teilt. (Ich vermute, dass für die Entwicklung eines großen Produkts wie Microsoft Windows das Team einfach zu groß ist, um das Maß an Zusammenarbeit aufrechtzuerhalten, mit dem ein zentrales VCS ohne Stellvertreter funktioniert, selbst wenn sich alle Personen im selben Gebäude befinden.)

3
Ken Bloom

Warum nicht zusammen verwenden? Bei meinem aktuellen Projekt sind wir gezwungen, CVS zu verwenden. Wir behalten jedoch auch lokale Git-Repositorys bei, um Features zu entwickeln. Dies ist das Beste aus beiden Welten, da Sie verschiedene Lösungen ausprobieren und Versionen Ihrer Arbeit auf Ihrem eigenen Computer aufbewahren können. Auf diese Weise können Sie auf frühere Versionen Ihrer Funktion zurücksetzen oder verschiedene Ansätze ausprobieren, ohne auf Probleme zu stoßen, wenn Sie Ihren Code durcheinander bringen. Ein zentrales Repository bietet Ihnen dann die Vorteile eines zentralen Repositorys.

2
Vadim

Ich habe keine persönlichen Erfahrungen mit DVCS, aber nach den Antworten hier und einigen verknüpften Dokumenten ist der grundlegendste Unterschied zwischen DVCS und CVCS das verwendete Arbeitsmodell

DVCS

Das Arbeitsmodell von DVCS ist, dass Sie isolierte Entwicklung tun. Sie entwickeln Ihr neues Feature/Bugfix isoliert von allen anderen Änderungen, bis Sie sich entscheiden, es für den Rest des Teams freizugeben. Bis zu diesem Zeitpunkt können Sie beliebige Check-Ins durchführen, da sich sonst niemand darum kümmern wird.

CVCS

Das Arbeitsmodell von CVCS (insbesondere Subversion) ist, dass Sie kollaborative Entwicklung ausführen. Sie entwickeln Ihr neues Feature/Bugfix in direkter Zusammenarbeit mit allen anderen Teammitgliedern und alle Änderungen stehen sofort allen zur Verfügung.

Andere Unterschiede

Andere Unterschiede zwischen svn und git/hg, wie z. B. Revisionen und Änderungssätze, sind zufällig. Es ist sehr gut möglich, ein DVCS basierend auf Revisionen (wie Subversion sie hat) oder ein CVCS basierend auf Änderungssätzen (wie Git/Mercurial sie haben) zu erstellen.

Ich werde kein bestimmtes Tool empfehlen, da es hauptsächlich von dem Arbeitsmodell abhängt, mit dem Sie (und Ihr Team) am besten vertraut sind.
Ich persönlich habe keine Probleme mit der Arbeit mit einem CVCS.

  • Ich habe keine Angst, Dinge einzuchecken, da ich keine Probleme habe, sie in einen unvollständigen, aber kompilierbaren Zustand zu bringen.
  • Als ich Merge-Hell erlebte, war es in Situationen, in denen es sowohl in svn als auch in git/hg aufgetreten wäre. Zum Beispiel wurde V2 einiger Software von einem anderen Team unter Verwendung eines anderen VCS gewartet, während wir V3 entwickelten. Gelegentlich mussten Bugfixes aus dem V2-VCS in das V3-VCS importiert werden, was im Grunde bedeutete, dass das V3-VCS sehr umfangreich eingecheckt wurde (mit allen Bugfixes in einem einzigen Änderungssatz). Ich weiß, dass es nicht ideal war, aber es war eine Entscheidung des Managements, verschiedene VCS-Systeme zu verwenden.