Warum scheinen alle DVCS eine irrationale Phobie unverbindlicher Veränderungen zu haben?

Ausgehend von einem SVN-Hintergrund ist es eines der schwierigsten Dinge, sich bei der Arbeit mit DVCS-Systemen daran zu gewöhnen, dass sie alle unverbindliche Änderungen als tickende Zeitbombe betrachten.

Wenn Sie in Mercurial versuchen, Änderungen abzurufen, und Sie nicht festgeschriebene Änderungen in Ihrer Arbeitskopie haben, müssen Sie durch die Rahmen springen, um die eingehenden Änderungen in zusammenzuführen. Versuchen Sie, Zweige zu wechseln? Es wird Sie zwingen, alles zurückzustellen, und dann müssen Sie alles am anderen Ende sofort aus dem Regal nehmen. (SVN hat mit keinem dieser Szenarien Probleme.)

Git ist ungefähr der gleiche Weg. Ich arbeite Seite an Seite mit einem anderen Entwickler an einem Projekt und habe nur versucht, einen seiner Commits in meine Gabel zu stecken. Es hat sich geweigert, mich zuzulassen, weil ich Änderungen an meiner Arbeitskopie in völlig anderen Dateien als den in seinem Commit geänderten nicht festgeschrieben habe. Es gibt nicht einmal eine Zusammenführungsoption. anscheinend muss ich zuerst meine Änderungen verstauen!

Wenn eine Person etwas völlig harmloses mit solch äußerster Vorsicht behandeln würde, würde ich es eine "Phobie" nennen, eine irrationale Angst, die als psychische Störung angesehen werden sollte. Aber Git und Mercurial wurden von zwei verschiedenen Teams intelligenter, rationaler Entwickler entworfen, daher muss ich mich fragen, ob sie etwas wissen, von dem ich nichts weiß.

Gibt es einen technischen Grund, der diese Haltung gegenüber unverbindlichen Änderungen rechtfertigt? Und wenn ja, warum scheint das fragliche Problem nur bei DVCS zu bestehen?

version-control dvcs

— Mason Wheeler
quelle

Ist das nicht der ganze Sinn dieser Dinge, den Sie in Ihrer lokalen Niederlassung einchecken können, trivial? Das Zusammenführen mit dem anderen Entwickler wird dann zu einer tatsächlichen Zusammenführung, anstatt zu versuchen, drei Quellen aufzulösen (Ihre Version, Ihre Änderungen, deren Version). Ich bin jedoch kein Experte auf diesem Gebiet, kann also außerhalb der Basis sein.

— Telastyn

Ich stimme Telastyn zu. Ich denke, der Grund, warum Sie auf scheinbar irrationale Einschränkungen stoßen, ist, dass Sie Git nicht auf idiomatische Weise verwenden. Eine der Hauptstärken von Git ist, dass Sie sich lokal festlegen können. Wenn ich den Code eines anderen in meine Arbeitskopie einfügen müsste, würde ich mich sicher zuerst lokal verpflichten. Lokale Commits sind billig, leicht zu bereinigen und ein erstaunliches Sicherheitsnetz. Ich bin nicht überrascht, dass sich Git-Workflows darum drehen (und folglich davon ausgehen, dass Warnungen und Einschränkungen davon ausgehen, dass Sie lieber festschreiben als an nicht festgeschriebenen Dateien arbeiten).

— MetaFight

@Telastyn: Nein, das können Sie nicht, da ein Einchecken - auch in Ihre lokale Niederlassung - einen Festschreibungsgrund erfordert und einen Datensatz im Verlauf erstellt. Wenn Sie also etwas einchecken, das noch nicht festgeschrieben werden konnte, und wenn Sie bereit sind, Änderungen in das Remote-Repository zu übertragen, wird dieser Verlauf dort angezeigt, es sei denn, Sie führen zusätzliche Vorgänge durch, um den Verlauf neu zu schreiben. Das passt zu keiner Definition von "trivial", die ich erkenne, und es scheint mir eine Menge zusätzlicher Komplexität ohne artikulierbaren Nutzen zu sein.

— Mason Wheeler

"Ja wirklich?" "Stabilisiertes XYZ für die Zusammenführung von Main" ist eine Belastung oder eine übermäßig höfliche Geschichte?

— Telastyn

Würden Sie ein Papier zur Veröffentlichung einreichen, ohne es aus Gründen der Klarheit zumindest zu bearbeiten? Dann reichen Sie Ihren ersten Entwurf einer Commit-Serie nicht zur Veröffentlichung ein. Tun Sie jedem, der Ihren Code liest, einen großen Gefallen: Gehen Sie zurück und produzieren Sie die Commit-Serie, die Sie geschrieben hätten, wenn Sie die Voraussicht gehabt hätten, dies überhaupt so zu tun. Interaktive Rebase ist nicht schwer ..

— bis

Antworten:

In der DVCS-Welt sind Commits billig und die Geschichte ist veränderlich. WIP kann so "schmutzig" sein, wie Sie möchten: und ich sehe keine Gründe gegen "Löschen meines aktuellen Status im Änderungssatz zum Speichern".
Der SVN-Verlauf ist daher linear. Sie müssen Ihre Entwürfe mit Änderungen aus neuen Revisionen zusammenführen. DVCS verwendet (natürlich) DAG, und zusätzlicher Kopf (Commit + Pull + Up) für divergierende Historie ist sicherer als das spontane Zusammenführen eines modifizierten Arbeitsverzeichnisses mit abgerufenen externen Änderungen
Wenn Sie in Subversion (zu einem Knoten ) modifiziertes WC wechseln , wird eine mögliche zusätzliche Zusammenführung beseitigt (im Gegensatz zu "Commit to Old" - "Switch" - "Merge 1 Rev. Range") ... und wir wissen: Merges in SVN sind nicht die perfekte Seite des Tools, während es für DVCSes überhaupt kein Problem ist

Fortsetzen

Es ist keine Phobie, es ist eine (manchmal harte) Durchsetzung der Befolgung guter Manieren "oft begehen" (SVN-Benutzer haben manchmal Angst vor diesem Stil).

Und endlich hg qnew|qpop|qpushist ein kleiner fairer Preis für Sauberkeit und Ordnung

— Fauler Dachs
quelle

Wenn Sie zusammenführen oder auswählen git, erstellen Sie sofort ein Commit. Der Vorgang ist erst abgeschlossen, wenn das Festschreiben abgeschlossen ist und Teil des Verlaufs ist.

Was würde nun passieren, wenn gitSie Ihre nicht festgeschriebenen Änderungen in Ihrem Arbeitsverzeichnis beschönigen könnten? Es fällt Ihnen (mehr oder weniger) schwer, zwischen den Änderungen / Zusammenführungskonflikten zu unterscheiden, die Sie für die Zusammenführung / Auswahl benötigen, und den Änderungen, die Sie selbst vorgenommen haben. Außerdem wäre es für Sie nahezu unmöglich zu testen, was Sie tatsächlich begehen.

Das Erzwingen eines sauberen Arbeitsverzeichnisses für Zusammenführungssituationen hilft daher, die Dinge einfach und überschaubar zu halten. Alles, was Sie tun müssen, ist, Ihre nicht festgeschriebenen Änderungen vor dem Zusammenführen zu speichern und sie anschließend zu entsorgen. Beachten Sie, dass im Workflow

git stash
git pull
git stash pop

Sie haben zwei (!) Zusammenführungsvorgänge. Eine, die Ihr letztes Commit mit den eingehenden Änderungen zusammenführt, und eine, die Ihre nicht festgeschriebenen Änderungen mit dem resultierenden Zusammenführungs-Commit zusammenführt. Auf diese Weise müssen Sie immer nur zwei Dinge zu einem zusammenführen, um die Verwirrung zu vermeiden, die sich aus dem Versuch ergibt, drei Dinge in einem einzigen Vorgang zu einem zusammenzuführen, während Sie versuchen, diese drei Dinge zu ignorieren. Das git stash/ git stash popmacht es einfach und explizit, dass Sie Ihre nicht festgeschriebenen Änderungen für die Zusammenführung ignorieren.

— cmaster - Monica wieder einsetzen
quelle