Was soll ich tun, wenn ich zwischen den Commits bereits zu lange gewartet habe?

100

Ich war ungezogen ... Zu viel "Cowboy-Codierung", zu wenig Commitment. Jetzt bin ich hier mit einem enormen Engagement. Ja, ich hätte mich die ganze Zeit verpflichten sollen, aber jetzt ist es zu spät.

Was ist besser?

Führen Sie eine sehr große Festschreibung durch, in der alle Dinge aufgelistet sind, die ich geändert habe
Versuchen Sie, es in kleinere Commits zu unterteilen, die sich wahrscheinlich nicht kompilieren lassen, da Dateien mehrere Korrekturen, Änderungen, zusätzliche Methodennamen usw. aufweisen.
Versuchen Sie, Dateien nur für entsprechende Festschreibungen teilweise umzukehren, und setzen Sie dann die neuen Änderungen zurück.

Hinweis: Ab sofort bin ich der einzige Programmierer, der an diesem Projekt arbeitet. Die einzige Person, die sich diese Commit-Kommentare ansieht, bin ich, zumindest bis wir mehr Programmierer einstellen.

Übrigens: Ich benutze SVN und Subclipse. Ich habe einen neuen Zweig erstellt, bevor ich diese Änderungen vorgenommen habe.

Weitere Informationen : Ich habe eine separate Frage gestellt, die sich darauf bezieht, wie ich überhaupt in diese Situation geraten bin: Wie bereite ich mich auf das Umschreiben des Klebstoffs einer Anwendung vor?

— durron597
quelle

2

Welches Versionskontrollprogramm verwenden Sie? Viele haben Module, mit denen Sie Ihre Änderungen in "Hunks" aufteilen können, dh Gruppen von geänderten Zeilen, mit denen Sie Ihre Änderungen nach Belieben gruppieren und die Mods einer Datei auf mehrere Änderungssätze verteilen können. ZB hat Mercurial die Erweiterung "Shelve". Natürlich sollten Sie immer noch prüfen, ob jeder Stapel von Änderungen kompiliert wird, wenn dies für Ihren Prozess von Bedeutung ist. Ob sich die Mühe lohnt, liegt bei Ihnen und Ihrem Geschäft.

— Alexis

6

Checken Sie es zumindest in einem Zweig ein, damit Sie Ihre Änderungen nicht verlieren.

— Rory Hunter

2

Sie können sich die Frage immer wieder stellen und noch länger warten, oder sich tatsächlich mit allem befassen, was Unordnung verursacht ... Und dann ... tun Sie es nicht noch einmal!

— Haylem

40

# 1, bete um Vergebung und gehe dann weiter und sündige nicht mehr :)

— Peteris

5

Die wichtigere Frage, die Sie sich stellen sollten, lautet: "Wie ändere ich meine schlechten Gewohnheiten, um zu verhindern, dass dies erneut geschieht?". Es sollte keinen Grund geben, sich mindestens einmal am Tag, besser öfter, zu verpflichten.

— Doc Brown

52

Um zu antworten, müssen Sie sich fragen, wie Sie die Ergebnisse dieser Commits in Zukunft nutzen wollen. Die häufigsten Gründe sind:

Um zu sehen, welche Version ein Fehler eingeführt wurde.
Um zu sehen, warum eine bestimmte Codezeile vorhanden ist.
In einem anderen Zweig zusammenführen.
Um in der Lage zu sein, eine frühere Version für die Fehlerbehebung eines Problems auszuchecken, wird dies einem Kunden oder Tester in dieser Version angezeigt.
In der Lage sein, bestimmte Teile von einer Freigabe einzuschließen oder auszuschließen.

Die ersten beiden Gründe lassen sich mit einem großen Check-in genauso gut erklären, vorausgesetzt, Sie können eine Check-in-Nachricht erstellen, die für jede Zeile mit geändertem Code gleichermaßen gilt. Wenn Sie der einzige Programmierer sind, werden kleinere Commits Ihre Zusammenführung nicht einfacher machen. Wenn Sie nicht vorhaben, eine Veröffentlichung oder einen Test mit nur einem Teil Ihrer nicht übermittelten Änderungen durchzuführen, gelten die letzten beiden Gründe nicht.

Es gibt andere Gründe, kleine Commits zu machen, aber diese Gründe sind gegeben, während Sie sich mitten in den Veränderungen befinden und diese Zeit vorbei ist. Diese Gründe machen es einfacher, einen Fehler oder eine experimentelle Änderung zu korrigieren und mit Kollegen synchron zu bleiben, ohne dass es zu großen Zusammenführungen kommt.

Nach meinem Verständnis Ihrer Situation, wie Sie sie beschrieben haben, scheint es wenig oder gar keinen Nutzen zu haben, Ihr Commit zu diesem Zeitpunkt aufzuteilen.

— Karl Bielefeldt
quelle

Hervorragende Antwort! Obwohl ich es nicht weniger bedaure, dass ich die kleinen Verpflichtungen nicht erfüllt habe, fühle ich mich viel wohler bei dem, was ich tun sollte, um wieder so produktiv wie möglich zu arbeiten.

— Durron597

1

Das andere , was etwa 3 und 5 ist , dass jede Arbeit , die Sie jetzt tun , um zu ermöglichen , sie passieren, Sie könnten warten , bis Sie es wirklich brauchen , und dann die gleiche Arbeit tun. In Zukunft wird es wahrscheinlich etwas schwieriger sein, weil Sie sich nicht mehr an das erinnern, was Sie getan haben. Aber Sie werden es wahrscheinlich nie brauchen.

— Steve Jessop

Nach meiner Erfahrung ist es mühsam und fragil, sich auf die Versionskontrollkommentare zu verlassen, um eine Geschichte zu erzählen, warum der Code vorhanden ist (dh Gründe 1 und 2). Wenn Sie SVN mit einer Verzweigung verwenden, geht der Festschreibungsverlauf ohnehin beim Zusammenführen verloren (mit moderneren Dingen wie Git sind Sie besser dran). Also das sind meiner Meinung nach am besten mit Kommentaren bedient.

— Hans-Peter Störr

1

@hstoerr - Wenn Sie mit Subversion 1.5 oder höher arbeiten, können Sie den Verlauf mit der Option --reintegrate beim Zusammenführen beibehalten.

— Dustin Kendall

1

git add -p ist dein bester Freund hier. Ich habe mich in dieses Feature verliebt. Auf diese Weise kann ich meine Codierungsstandardänderungen in separaten Commits festschreiben und die relevanten Codeänderungen isoliert lassen.

— Spidey

39

Ich denke, was auch immer Sie tun, versuchen Sie zu vermeiden, Code einzuchecken, von dem Sie wissen, dass er nicht kompiliert werden kann.

Wenn Sie der Meinung sind, dass Ihre dritte Option durchführbar ist, ist dies möglicherweise eine gute Möglichkeit, sofern Sie sicherstellen können, dass Ihre Folge von Festschreibungen kein nicht kompilierbares System erzeugt. Ansonsten machen Sie einfach das eine große Commit. Es ist hässlich, aber es ist einfach, schnell und erledigt es. Gehen Sie vorwärts, legen Sie öfter fest .

— FrustratedWithFormsDesigner
quelle

Option drei ist möglich, aber sehr zeitaufwendig. Ich glaube, ich mache nur Option 1

— durron597

3

Was sind die Nachteile des Festschreibens von Code, der nicht in einem Feature-Zweig (oder ähnlichem) kompiliert oder erstellt werden kann, der so schrecklich ist, dass er jemanden dazu zwingt, es zu vermeiden, "was auch immer er tut"? Ich könnte mir vorstellen, dass andere wirklich schreckliche Commits vermeiden könnten. Dies ist der einzige wahre Grund, warum ich sie überhaupt vermeiden würde (vorausgesetzt natürlich, dass die Commits nicht veröffentlicht werden ).

— Kenny Evitt

3

Die Option "Vermeiden Sie das Einchecken von Code, der nicht kompiliert werden kann" gilt nur für eine gemeinsam genutzte Codebasis / -verzweigung. Bei einem Ein-Mann-Projekt oder einer Ein-Mann-Entwicklungsabteilung ist es meiner Meinung nach wichtiger, nur Ihre Änderungen in VC zu übernehmen, damit Sie nichts verlieren.

— Stephen C

3

@StephenC zum Beispiel, weil es Werkzeuge wie Git-Bisect bricht. Wenn Code die ganze Zeit kompiliert / ausgeführt wird und Sie eine Regression finden müssen, wenn er die ganze Zeit kompiliert, können Sie einfach binär suchen es runter).

— Maciej Piechotka

@MaciejPiechotka - Wenn Sie bestimmte Tools für Ihre privaten Zweige benötigen und dieser Code kompilierbar sein muss, sollten Sie dies natürlich tun. Aber das ist nicht typisch für ein Ein-Personen-Projekt / eine Ein-Personen-Branche.

— Stephen C

19

Der wichtigste Grund für häufige, kleine und aussagekräftige Commits ist das Verständnis der Geschichte des Codes. Insbesondere ist es sehr schwer zu verstehen, wie sich Code verändert hat, wenn es schwierig ist, verständliche Unterschiede zu generieren.

Option 1 verschleiert den Verlauf der von Ihnen vorgenommenen Änderungen, führt jedoch ansonsten nicht zu Problemen.

Option 2 verschleiert den Verlauf der von Ihnen vorgenommenen Änderungen, möglicherweise etwas weniger als Option 1, kann jedoch andere Probleme für Sie oder andere verursachen, wenn sie annehmen oder auf andere Weise den Schluss ziehen, dass die Commits unterschiedlich sind, z. B. unabhängig voneinander in anderen Zweigen zusammengeführt werden können. Dies ist weniger ideal, es sei denn, es gibt einen starken praktischen Grund, warum dies Option 1 vorgezogen wird.

Option 3 ist am besten, da alle anderen Faktoren gleich sind. Wenn dies jedoch, wie Sie an anderer Stelle beschrieben haben, "extrem" viel Zeit in Anspruch nehmen oder andere erhebliche Kosten verursachen würde, müssen Sie diese Kosten mit den erwarteten Vorteilen von abwägen sauberere Commits erstellen.

Anhand der von Ihnen angegebenen Informationen würde ich mich für Option 1 entscheiden. Vielleicht sollten Sie Erinnerungen einrichten, die Sie auffordern, Ihre Änderungen zu übernehmen?

Prototyping und Umschreiben

Eine weitere Überlegung, die Sie berücksichtigen sollten, insbesondere angesichts Ihres Hinweises, dass Sie der einzige Programmierer sind, und meiner Vermutung, dass Sie an einer relativ neuen Codebasis arbeiten, ist, dass es wahrscheinlich gut ist, unterschiedliche Gewohnheiten zu entwickeln, um Änderungen für Sie vorzunehmen Prototyping von neuem Code statt Beibehalten oder Erweitern von vorhandenem Code. Es gibt wahrscheinlich keine besonders scharfe Trennung zwischen den beiden, aber ich denke, es ist immer noch eine nützliche Unterscheidung.

Wenn Sie einen neuen Code als Prototyp erstellen, müssen Sie die Änderungen immer dann festschreiben, wenn Sie sie speichern möchten, mit ziemlicher Sicherheit in einem Zweig, aber möglicherweise in einem separaten Projekt. Oder vielleicht sogar nur außerhalb der Versionskontrolle arbeiten. Sie können sich stattdessen darauf konzentrieren, Beweise für die Machbarkeit verschiedener Hypothesen oder Entwürfe zu sammeln, die Sie in Betracht ziehen. Ich schreibe oft kleine Prototypen mit verschiedenen Tools, z. B. LINQPad anstelle von Visual Studio für C # -Code.

Wenn Sie eine bestimmte Hypothese oder ein bestimmtes Design validiert haben, schreiben Sie es in Ihrem Hauptprojekt um, idealerweise in einem Zweig, und treffen Sie die kleinen, aussagekräftigen Festlegungen, die das Verständnis anderer (einschließlich Ihrer zukünftigen) in Bezug auf die Art der Änderungen am besten unterstützen du machst.

— Kenny Evitt
quelle

1

Gute Antwort; Kenny, haben Sie einen guten Artikel oder eine andere Wissensdatenbank, die Sie mit genaueren Details zum Prototyping verknüpfen können? Meine Version des Prototyping ist "Skizze im Notizbuch oder auf Whiteboard"

— durron597

@ durron597, mir fallen keine Links (auch nicht zum Suchen) ein. Ich habe mit genügend interpretierten (und dynamisch kompilierten) Programmiersprachen gespielt, die ich nicht einmal für neuartig hielt! Und ich habe so viele C-, C ++ - und Java-Programme (immer wieder) umgeschrieben, dass ich nicht dachte, dass das auch ungewöhnlich oder zumindest für einige neu sein könnte.

— Kenny Evitt

12

Obwohl die einzig vernünftige Antwort darin besteht, niemals den Kofferraum zu knacken , ist dies manchmal nicht möglich. Zum Beispiel kann svn das Festschreiben unterbrechen, wenn Sie zu viel festschreiben (möglicherweise eine Option oder eine Funktion, bei der ich mir nicht sicher bin). In solchen besonderen Fällen einfach in Stücken einchecken. Da Sie ein einzelner Programmierer sind, wird es niemanden stören.

Daher würde ich Option 1 wählen. Wenn dies nicht möglich ist, Option 2.

Option 3 erfordert viel Aufwand und ist es einfach nicht wert.

— BЈовић
quelle

1

oder markieren Sie die nicht kompilierten Versionen als "DOESN'T COMPILE"

— Ratschenfreak

2

@ratchetfreak: Ich denke, ein "Tag" in SVN hilft nicht viel, da Tags nicht als "Kommentare" im Trunk funktionieren.

— Doc Brown

@DocBrown Ich wollte es der Commit-Nachricht hinzufügen

— Ratschenfreak

5

@ratchetfreak Ich würde es als "TEIL X / N: Einchecken ABC - NICHT KOMPILIEREN"

— B --овић

Option 3 erfordert keinen großen Aufwand. Eine andere Antwort erklärt, wie man es schnell und einfach mit git add --patchund macht git stash. Die Situation scheint nur aufgrund veralteter Tools und Kenntnisse zur Quellcodeverwaltung schwierig.

— Ron MacNeil

7

Versuchen Sie, es in kleinere Commits zu unterteilen, die sich wahrscheinlich nicht kompilieren lassen, da Dateien mehrere Korrekturen, Änderungen, zusätzliche Methodennamen usw. aufweisen.

Wenn ich mich in einer ähnlichen Situation befunden habe, habe ich die folgende Technik angewendet:

Fügen Sie nur den Code hinzu, der für eine bestimmte Funktion relevant ist: git add --patch
Verstecken Sie alle anderen Änderungen: git stash save --keep-index
Führe Tests aus / versuche zu kompilieren
Änderungen festschreiben, wenn alles in Ordnung ist, wenn nicht mit 1 fortfahren

Ich bin nicht mit SVN vertraut, daher weiß ich nicht, ob dies auf Ihre spezielle Situation zutrifft, aber die Grundlage sollte dieselbe sein - isolieren Sie kleine Teile des Codes und testen Sie sie einzeln.

— Milos
quelle

Ich mag das, aber leider ist eines der vielen Dinge auf meiner ToDo-Liste (es gibt eine Menge, wenn Sie der einzige Tech-Typ in einem Unternehmen sind), von SVN zu Git zu wechseln, und ich bin einfach noch nicht dazu gekommen .

— Durron597

1

Da ich nicht genug bin, um es zu verwenden --patch, verwende ich Rückgängig in verschiedenen Editorfenstern , um zu früheren Arbeitszuständen zu gelangen und diese festzuschreiben . Dann wiederhole ich für das nächste Commit. Aus der Versuchung heraus, den Code im Status "Undone" geringfügig zu ergänzen, erstelle ich immer eine Sicherungskopie, bevor ich diesen Vorgang beginne!

— Joeytwiddle

Mit git können Sie auch vor dem Festschreiben interaktiv hinzufügen (add -i) und danach verzweigen, um Ihre Festschreibungen unabhängig zu validieren.

— Riezebosch

3

Wie wäre es mit Option 4: Sichern Sie den aktuellen Status Ihres Repos an einem temporären Ort, stellen Sie den ursprünglichen Status Ihres Repos wieder her, erstellen Sie eine Liste aller vorgenommenen Änderungen (Sie können sich die temporäre Sicherung weiterhin ansehen), und führen Sie dann eine manuelle Neuimplementierung durch (und kompilieren Sie sie und teste!) sie als separate Commits.

Dies sollte einfacher sein, da Sie den Code bereits geschrieben haben. Sie müssen lediglich herausfinden, welche Teile Sie aus Ihrer temporären Sicherung kopieren und einfügen müssen.

Wenn Sie jede Änderung sauber erneut implementiert haben und damit sichergestellt haben, dass die Commits in sich geschlossen, klein und kompiliert sind, können Sie die temporäre Sicherung löschen, und alles wird fast genau so sein (mit Ausnahme der Uhrzeit / des Datums der Commits) wäre es gewesen, wenn Sie es von Anfang an richtig gemacht hätten.

— Super
quelle

Dies ist nur eine Möglichkeit, Option 3 durchzuführen. Wahrscheinlich der beste Weg, wahr, aber immer noch ziemlich zeitaufwändig.

— Durron597

Es gab 149 Zeilen zum Hinzufügen / Löschen / Senden von Nachrichten, als ich das eine große Commit ausgeführt habe. Das dauert mindestens einen halben Tag.

— Durron597

@ Durron597 Ich bin anderer Meinung, ich denke, das ist anders als # 3. Wie viel Wert legen Sie bei 149 Zeilen auf einen sauberen Commit-Verlauf? Lohnt sich ein halber Tag? Wie auch immer, es ist nicht so, dass die anderen Methoden nicht erfordern, herauszufinden, welche Zeile in welcher Festschreibung enthalten sein soll, daher müssen Sie die 149 Zeilen in beiden Richtungen durchgehen. Der Zeitunterschied wird gering sein.

— Superbest

Heh. Ich bin erfahren genug, um zu wissen, wie man die Versionskontrolle einsetzt, aber nicht erfahren genug, um es jemals außer meinem Hintern zu haben.

— Durron597

Sie müssen nicht Ihr gesamtes Repo sichern . Sie können ein Backup-Commit durchführen und dann den HEAD mit zurücksetzen git reset HEAD~. Ihr Commit bleibt bestehen, git reflogwenn Sie später entscheiden, dass Sie es benötigen. Sie können sogar einen Zweig abspalten (und dann zum Arbeitszweig zurückwechseln), bevor Sie den Reset ausführen, um Ihrem "Backup" einen Namen zu geben. Löschen Sie den Zweig später, wenn Sie ihn nicht benötigen. Edit: Sorry nicht realisiert, dass OP auf SVN ist!

— Joeytwiddle

3

Du bist der einzige Programmierer; Machen Sie einfach einen einzigen massiven Check-in, in dem die wichtigen Teile Ihres Tuns aufgeführt sind.

Werden Sie wahrscheinlich "Teile" von dem zurücksetzen, was Sie getan haben? Wenn nicht, fahren Sie unbedingt mit Option 1 fort.

Es gibt mehrere Gründe, Code in ein Versionskontrollsystem einzuchecken. Und ALLE von ihnen, wenn Sie der einzige Entwickler sind, drehen sich um die Sicherheit - wenn Sie nämlich Fehler machen, die Maschine ausfällt oder was auch immer, können Sie immer zu diesem letzten Kontrollpunkt zurückkehren.

Es ist unwahrscheinlich, dass ein Programmierer, der später in das Projekt eintritt, auf eine Version zurücksetzen möchte, die nicht kompiliert werden kann. Also, meiner Meinung nach, Option 2 ist Wahnsinn.

Option 3 klingt nach einer solchen Zeitverschwendung, dass ich, wenn ich Ihr Chef wäre und Sie Stunden damit verschwenden sehen würde, ein kleines Gespräch mit Ihnen darüber führen würde, was Ihre Zeit wert ist.

Um zu iterieren: Indem Sie Ihren Code einchecken, werden Sie Ihren Hintern im Falle eines Fehlers auf Ihrem Computer abdecken / retten. Alles andere in einem Ein-Mann-Team ist Schaufensterdekoration.

— Nicht ich
quelle

1

Ein Rollback ist nicht der einzige Grund, kleine Commits zu verwenden. Es ist nicht einmal ein besonders guter Grund. Der Hauptgrund besteht darin, festzustellen, wann und warum eine Änderung vorgenommen wurde, und die Fehlerbehebung zu vereinfachen, wenn Sie mit einem Problem unbekannter Herkunft konfrontiert sind. Ein anderer Programmierer, der später in das Projekt eintritt, wird mit ziemlicher Sicherheit zumindest gelegentlich auf Codezeilen stoßen, die ihn dazu bringen, "WTF" zu wählen und auf das Commit zu verweisen, in dem es zuerst geschrieben oder zuletzt geändert wurde. Wenn dieses Commit ein einziges großes Commit ist, das 500 Dinge ändert, ist es unmöglich, nützliche Informationen aus dem Verlauf zu erhalten.

— Aaronaught

Übrigens hassen Teams, die Git verwenden, Merge-Commits und fordern / fordern stattdessen Rebases an. Merge Commits Break bisectund andere Techniken, die häufig verwendet werden, um Probleme zu isolieren, weil so viele Änderungen zu einem großen Commit zusammengefasst werden.

— Aaronaught

1

Auf persönlicher Ebene stimme ich zu, dass Sie keine großen Commits ausführen sollten, es sei denn, Sie ändern radikal eine Codebasis. An diesem Punkt hätten Sie sie trotzdem verzweigen sollen. Es handelt sich jedoch um einen einzelnen Programmierer, der im Wesentlichen getrennt gearbeitet hat und jetzt versucht, wieder das Richtige zu tun. In diesem Fall halte ich ein großes Commit für vorzuziehen.

— NotMe

1

@Aaronaught Ich würde hinzufügen, dass Sie selbst 3 Monate später einen "anderen Programmierer" darstellen können.

— Maciej Piechotka

1

Ich muss auch nicht zustimmen, dass Verzweigungen eine tragfähige Strategie für architektonische Veränderungen oder andere "destruktive" Veränderungen sind. Das führt nur zu einem Albtraum von Zusammenführungskonflikten und Post-Merge-Fehlern. Auf lange Sicht ist es weitaus weniger schmerzhaft, einen Weg zu finden, um die Hauptänderung in kleinere, abwärtskompatible Änderungen zu unterteilen, oder im schlimmsten Fall das zu verwenden, was Fowler, Humble und der Rest von ihnen Branch nennen Durch Abstraktion (die eigentlich gar kein Zweig ist). Beide Strategien setzen kleine und fokussierte Commits voraus.

— Aaronaught

2

Meine Regel lautet: Kein Einchecken ohne ernsthafte Codeüberprüfung. Wenn ich alleine bin, muss ich den Code selbst überprüfen , aber er wird überprüft. Sie scheinen eine Menge von Codeänderungen zu haben, die nicht von jemand anderem überprüft werden konnten, daher können Sie diese nicht selbst überprüfen (das Überprüfen Ihres eigenen Codes ist schwieriger und erfordert mehr Disziplin, da Sie automatisch die falsche Annahme treffen, dass Ihr eigener Code korrekt ist ).

Die absolut unzerbrechliche Regel aller lautet: Checken Sie niemals Code ein, der noch nicht einmal erstellt wurde, und vermeiden Sie ernsthaft das Einchecken von Code, der nicht funktioniert.

Lösung: Kopieren Sie den geänderten Code und kehren Sie zum ursprünglichen Punkt zurück. Führen Sie jeweils eine Änderung in den Originalcode ein, überprüfen Sie ihn, testen Sie ihn und checken Sie ihn ein. Mit der von Ihnen beschriebenen Programmiermethode werden Sie auf diese Weise sicher einige schwerwiegende Fehler finden.

Es ist auch eine gute Möglichkeit, sich in gute Programmiergewohnheiten einzuarbeiten.

— gnasher729
quelle

Dies ist logischerweise das Gleiche wie die Git-basierte Antwort oben ( git add --patchund git stash) und ein gutes Beispiel für ein Szenario, mit dem moderne DVCS problemlos umgehen können, ältere Systeme jedoch nicht.

— Ron MacNeil

1

Ich denke, Sie machen sich viel zu viele Sorgen. Wenn Sie der einzige Programmierer sind und kein Datenblatt haben, gegen das Sie arbeiten können, liegt es ganz bei Ihnen, was Sie tun. Ich gehe davon aus, dass Sie niemand dafür bestrafen wird, dass Sie eine große Festschreibung getätigt haben. Die einzigen Probleme, auf die Sie stoßen, sind technische Probleme, z. Da Sie in diesem Moment die alleinige Kontrolle über das Repo haben, sollte das auch kein großes Problem sein.

Es ist eine Grenze zwischen Pragmatismus und Dogmatismus zu ziehen. Was Sie getan haben, wäre keine gute Idee in einem Team und sollte in Zukunft wahrscheinlich nicht wiederholt werden, aber in Ihrer Situation würde ich nur das große Commit einreichen.

— Roy
quelle

1

Dies scheint nichts Wesentliches über das hinzuzufügen, was bereits in den vorherigen 12 Antworten gepostet wurde

— Mücke

-1

Das Problem liegt nicht in langen Verzögerungen zwischen Commits, sondern darin, dass Sie den Code zu lange im nicht kompilierbaren Zustand halten. Was ist Ihre Definition von "lang"? Für einige Leute sind 5 Minuten für den Übergangszustand zu viel, aber einige können ihren Code tagelang polieren, ohne überhaupt zu versuchen, den Compiler auszuführen.

Tatsächlich spielt es keine Rolle - wichtig ist, dass Sie die Kontrolle über Ihren Code verloren haben und Ihr Code nicht mehr verwaltet werden kann. Das ist normal, es bedeutet nur, dass Sie technologische Schulden haben und es Zeit ist, über das Refactoring nachzudenken. Sie sind also frustriert? Ihr Code lässt sich nicht kompilieren, Sie haben noch nicht einmal Unit-Tests? Wie können Sie in diesem Fall über ein Refactoring nachdenken? Keine Bange. Beenden Sie Ihre "Cowboy-Codierung" und beginnen Sie mit der Reinigung. Versuchen Sie im Idealfall, einige Tests zu schreiben. Sie haben keine Zeit dafür? Ok, fange mit kleinen Verbesserungen an.

Einige Änderungen erfordern keine Tests. Ändern Sie den Variablennamen, um ihn besser zu verwenden, verschieben Sie sich wiederholenden Code in eine separate Funktion usw. Sie erhalten eine bessere Vorstellung von Ihrem Code. Danach können Sie größere Änderungen vornehmen. Versuchen Sie nach Möglichkeit erneut, Tests zu schreiben. Machen Sie Ihren Code überschaubar.

Danach werden Sie feststellen, dass die nächste Änderung nicht "zu lange" dauert (was auch immer dies bedeutet).

— AlexT
quelle

2

Er sagte nicht, dass er den Code für eine lange Zeit unkompilierbar hielt. Der Code im Repo war lange Zeit unverändert, aber immer noch kompilierbar. Der Code in seiner Arbeitskopie wurde häufig aktualisiert, aber nicht festgeschrieben. Nichts in der Frage deutet darauf hin, dass sein Code möglicherweise umgestaltet werden muss - "Cowboy-Codierung" bezieht sich hier auf seinen SCM-Workflow, nicht auf die tatsächliche Codequalität

— Idan Arye

@IdanArye Von der ursprünglichen Frage ...Try to break it into smaller commits that likely won't compile...Wenn etwas Sie daran hindert, Ihren Code zu schreiben, ist es bereits eine gute Sache, diesen Code zu verwalten. "Commit" ist nur eine der Möglichkeiten, um Ihre Arbeit fortzusetzen. Wir können über einen extremeren Fall nachdenken - "wenn mich etwas daran hindert, die Quelldatei zu speichern". Also was könnte es sein? Ich denke, es ist Angst vor deinen eigenen Veränderungen. Warum kann es sein? ... Ich denke, Sie haben es verstanden

— AlexT

2

Mir scheint es eher so, als wäre es nur Faulheit, die ihn daran hinderte, etwas zu begehen.

— Idan Arye

@IdanArye In jeder Hinsicht sind Sie richtig. Das plus nicht genug TDD, was ein separates Problem ist.

— Durron597

@AlexT Betrachten Sie ein Szenario, in dem Sie zwei Fehler beheben und einer von ihnen eine neu entwickelte Methode erfordert. Wenn Sie ordnungsgemäß festgeschrieben haben, beheben Sie einen Fehler, führen eine Festschreibung durch und beheben dann den anderen Fehler. Wenn dies nicht der Fall ist, müssen Sie beim Festschreiben entweder beide Änderungen in dasselbe Festschreiben einbeziehen oder die erste Fehlerbehebung mit den Änderungen für das zweite festschreiben, es sei denn, die festgeschriebene Version verfügt nicht über den neuen Methodenaufruf und daher kompiliert nicht.

— Durron597