it-swarm.com.de

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

Ich war ungezogen ... Zu viel "Cowboy-Codierung", nicht genug Commit. 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?

  1. Führen Sie ein sehr großes Commit durch, indem Sie alle Dinge auflisten, die ich geändert habe
  2. Versuchen Sie, es in kleinere Commits aufzuteilen, die wahrscheinlich nicht kompiliert werden können, da Dateien mehrere Korrekturen, Änderungen, zusätzliche Methodennamen usw. enthalten.
  3. Versuchen Sie, Dateien nur für entsprechende Commits 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 einen dieser 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 eine dieser Änderungen vorgenommen habe.

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

103
durron597

Um zu antworten, müssen Sie sich fragen, wie Sie die Ergebnisse dieser Commits in Zukunft voraussichtlich verwenden werden. 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 einen anderen Zweig einbinden.
  • Um eine frühere Version zur Fehlerbehebung bei einem Problem überprüfen zu können, das ein Kunde oder Tester in dieser Version sieht.
  • Um bestimmte Teile in eine Version einschließen oder ausschließen zu können.

Die ersten beiden Gründe können mit einem großen Check-in genauso gut bedient werden, vorausgesetzt, Sie können eine Check-in-Nachricht erstellen, die für jede Zeile des geänderten Codes gleich gut gilt. Wenn Sie der einzige Programmierer sind, werden kleinere Commits das Zusammenführen nicht einfacher machen. Wenn Sie nicht vorhaben, eine Veröffentlichung oder einen Test nur mit einem Teil Ihrer nicht eingereichten Änderungen durchzuführen, gelten die letzten beiden Gründe nicht.

Es gibt andere Gründe für kleine Commits, aber diese sind, während Sie sich mitten in den Änderungen befinden und diese Zeit vorbei ist. Diese Gründe machen es einfacher, einen Fehler oder eine experimentelle Änderung rückgängig zu machen, und es einfacher, mit Kollegen synchron zu bleiben, ohne große, beängstigende Zusammenschlüsse.

Nach meinem Verständnis Ihrer Situation, wie Sie sie beschrieben haben, scheint es wenig bis gar keinen Vorteil zu haben, Ihr Commit an dieser Stelle aufzuteilen.

53
Karl Bielefeldt

Ich denke, was auch immer Sie tun, versuchen Sie zu vermeiden, Code einzuchecken, den Sie wissen nicht kompilieren werden.

Wenn Sie der Meinung sind, dass Ihre dritte Option machbar ist, ist dies möglicherweise ein guter Weg, solange Sie sicherstellen können, dass Ihre Abfolge von Commits kein nicht kompilierbares System erzeugt. Andernfalls machen Sie einfach das eine große Commit. Es ist hässlich, aber es ist einfach, schnell und erledigt es. In Zukunft häufiger festlegen.

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 geändert hat, wenn es schwierig ist, verständliche Unterschiede zu generieren.

Option 1 verschleiert den Verlauf der von Ihnen vorgenommenen Änderungen, verursacht sonst jedoch keine Probleme.

Option 2 verschleiert den Verlauf der von Ihnen vorgenommenen Änderungen, möglicherweise etwas weniger als Option 1, aber es könnte andere Probleme für Sie selbst oder andere verursachen, wenn sie annehmen oder auf andere Weise zu dem Schluss kommen, dass die Commits unterschiedlich sind, z. kann unabhängig in andere Zweige zusammengeführt werden. Sofern es keinen starken praktischen Grund gibt, warum dies Option 1 vorgezogen wird, ist dies weniger ideal als es.

Option ist am besten, wenn alle anderen 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 abwägen diese Kosten gegen die erwarteten Vorteile der Schaffung sauberer Verpflichtungen.

Basierend auf den 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 Ihrer Bemerkung, der einzige Programmierer zu sein, und meines Verdachts, dass Sie an einer relativ neuen Codebasis arbeiten, ist, dass es wahrscheinlich gut ist, unterschiedliche Gewohnheiten zu entwickeln, um Änderungen vorzunehmen, wenn Sie dies tun Prototyping von neuem Code im Vergleich zur Pflege oder Erweiterung von vorhandenem Code. Es gibt wahrscheinlich keine schrecklich scharfe Trennung zwischen den beiden, aber ich denke, es ist immer noch eine nützliche Unterscheidung.

Wenn Sie Prototypen für neuen Code erstellen, legen Sie fest, wann immer Sie Ihre Änderungen speichern möchten, mit ziemlicher Sicherheit in einem Zweig, aber möglicherweise in einem separaten Projekt. Oder arbeiten Sie einfach außerhalb der Versionskontrolle. 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 Werkzeugen, z. 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, idealerweise in einem Zweig, neu und treffen Sie die kleinen, aussagekräftigen Zusagen, die das Verständnis anderer (einschließlich Ihres zukünftigen) hinsichtlich der Art der Änderungen am besten unterstützen du machst.

19
Kenny Evitt

Obwohl die einzig vernünftige Antwort lautet: niemals den Kofferraum zerbrechen , 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 Sonderfällen einfach in Teilen einchecken. Da Sie ein einzelner Programmierer sind, wird es niemanden stören.

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

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

12
BЈовић

Versuchen Sie, es in kleinere Commits aufzuteilen, die wahrscheinlich nicht kompiliert werden können, da Dateien mehrere Korrekturen, Änderungen, zusätzliche Methodennamen usw. enthalten.

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

  1. Fügen Sie nur den Code hinzu, der für eine bestimmte Funktion relevant ist: git add --patch
  2. Verstecke alle anderen Änderungen: git stash save --keep-index
  3. Führen Sie Tests aus/versuchen Sie zu kompilieren
  4. Änderungen festschreiben, wenn alles in Ordnung ist, wenn nicht, gehe zu 1

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

7
Milos

Wie wäre es mit Option 4: Sichern Sie den aktuellen Status Ihres Repos an einem temporären Ort, setzen Sie Ihr Repo auf den ursprünglichen Status zurück, erstellen Sie eine Liste aller vorgenommenen Änderungen (Sie können sich die temporäre Sicherung weiterhin ansehen) und implementieren Sie sie erneut manuell (und kompilieren Sie sie) und testen!) sie als separate Commits.

Dies sollte einfacher sein, da Sie den Code bereits geschrieben haben. Sie müssen nur herausfinden, welche Teile aus Ihrer temporären Sicherung kopiert und eingefügt werden müssen.

Wenn Sie jede Änderung sauber neu implementiert und somit sichergestellt haben, dass 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 gewesen, wenn du es von Anfang an richtig gemacht hättest.

3
Superbest

Du bist der einzige Programmierer; Führen Sie einfach einen einzigen massiven Check-in durch, in dem die wichtigen Details Ihrer Arbeit aufgeführt sind.

Werden Sie wahrscheinlich "Teile" von dem, was Sie getan haben, zurücksetzen? 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 Sicherheit - wenn Sie es vermasseln, die Maschine stirbt oder was auch immer, können Sie immer zu diesem letzten Kontrollpunkt zurückkehren.

Ein Programmierer, der später in das Projekt eintritt, möchte wahrscheinlich nicht auf eine Version zurücksetzen, die nicht kompiliert werden kann. Also, IMHO, Option 2 ist Wahnsinn.

Option 3 klingt nach einer solchen Zeitsenke. Wenn ich Ihr Chef wäre und Sie Stunden damit verschwenden würden, würde ich ein wenig mit Ihnen darüber sprechen, was Ihre Zeit wert ist.

Um es zu wiederholen: Indem Sie Ihren Code einchecken, decken Sie Ihren Hintern ab/speichern ihn im Falle eines Ausfalls auf Ihrem Computer. Alles andere in einem Ein-Mann-Team ist Schaufensterdekoration.

3
NotMe

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 Reihe von Codeänderungen zu haben, die von niemand anderem überprüft werden konnten, daher können Sie sie 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 völlig unzerbrechliche Regel aller lautet: Checken Sie niemals Code ein, der nicht einmal erstellt wurde, und vermeiden Sie ernsthaft das Einchecken von Code, der nicht funktioniert.

Lösung: Kopieren Sie Ihren 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 sie, testen Sie sie und checken Sie sie ein. Mit der von Ihnen beschriebenen Programmiermethode werden Sie auf diese Weise einige schwerwiegende Fehler finden.

Es ist auch eine gute Möglichkeit, sich mit guten Programmiergewohnheiten vertraut zu machen.

2
gnasher729

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 ein großes Commit durchgeführt haben. Die einzigen Probleme, auf die Sie stoßen werden, sind technologische Probleme, z. B. die Möglichkeit, einzelne Dateiänderungen innerhalb des Commits nicht zurückzusetzen. Da Sie in diesem Moment allein die Kontrolle über das Repo haben, sollte dies jedoch auch kein großes Problem sein.

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

1
Roy