it-swarm.com.de

Wie oft müssen Änderungen an der Quellcodeverwaltung vorgenommen werden?

Wie oft sollte ich Änderungen an der Quellcodeverwaltung vornehmen? Nach jedem kleinen Feature oder nur nach großen Features?

Ich arbeite an einem Projekt und habe eine langfristige Funktion zu implementieren. Gegenwärtig werde ich nach jedem Teil der Arbeit einen Commit durchführen, d. H. Nach jeder implementierten und behobenen Unterfunktion. Ich begebe mich sogar, nachdem ich einen neuen Testblock für eine Funktion hinzugefügt habe, nachdem ich einen Fehler entdeckt habe.

Ich bin jedoch besorgt über dieses Muster. An einem produktiven Arbeitstag könnte ich 10 Commits machen. Angesichts der Tatsache, dass ich Subversion verwende, wirken sich diese Commits auf das gesamte Repository aus. Ich frage mich, ob es wirklich eine gute Praxis ist, so viele zu erstellen.

194
Eli Bendersky

Jedes Mal, wenn ich einen vollständigen Code-Gedanken vervollständige, der kompiliert und ausgeführt wird, checke ich ein. Dies dauert normalerweise zwischen 15 und 60 Minuten. Manchmal kann es länger dauern, aber ich versuche immer einzuchecken, ob ich viele Codeänderungen habe, die ich im Falle eines Fehlers nicht umschreiben möchte. Normalerweise stelle ich auch sicher, dass mein Code kompiliert wird und checke am Ende des Arbeitstages ein, bevor ich nach Hause gehe.

Ich würde mir keine Sorgen machen, zu viele Commits/Check-Ins zu tätigen. Es ist wirklich zum Kotzen, wenn Sie etwas umschreiben müssen, und es ist schön, in kleinen Schritten ein Rollback durchführen zu können, nur für den Fall.

188

Wenn Sie sagen, dass Sie besorgt sind, dass sich Ihre "Commits auf das gesamte Repository auswirken" - beziehen Sie sich auf die Tatsache, dass sich die Revisionsnummer des gesamten Repository erhöht? Ich weiß nicht, wie viele Bits Subversion zum Speichern verwendet, aber ich bin mir ziemlich sicher, dass Ihnen die Revisionsnummern nicht ausgehen werden! Viele Commits sind kein Problem. Sie können zehnmal häufiger als der Typ von nebenan Commits durchführen und erhöhen Ihren CO2-Fußabdruck überhaupt nicht.

Eine einzelne Funktion oder Methode sollte nach ihrer Funktion benannt werden, und wenn der Name zu lang ist, tut sie zu viel. Ich versuche, beim Einchecken die gleiche Regel anzuwenden: Der Check-in-Kommentar sollte genau beschreiben, was die Änderung bewirkt, und wenn der Kommentar zu lang ist, ändere ich wahrscheinlich zu viel auf einmal.

79
benzado

Ich mag diesen kleinen Artikel von Jeff Atwood: Früh einchecken, oft einchecken

34
CMS

Ich persönlich schreibe jede logische Codegruppe fest, die fertig ist/stable/compiles und versuche, den Tag nicht zu verlassen, ohne zu schreiben, was ich an diesem Tag getan habe.

24
Kevin Sheffield

Wenn Sie größere Änderungen vornehmen und sich Sorgen machen, dass andere an dem Code arbeiten, können Sie eine neue Verzweigung erstellen und nach Abschluss der Änderungen wieder in den Trunk einbinden.

20
smo

Ich verpflichte mich jedes Mal, wenn ich mit einer Aufgabe fertig bin. Das dauert normalerweise 30 Minuten bis 1 Stunde.

12
jop

Wenn Ihr Versionskontrollkommentar länger als ein oder zwei Sätze ist, legen Sie wahrscheinlich nicht oft genug fest.

11
jmort253

Schreiben Sie keinen Code fest, der nicht funktioniert. Verwenden Sie Ihr Repository nicht als Backup-Lösung.

Sichern Sie stattdessen Ihren unvollständigen Code automatisch lokal. Time Machine kümmert sich um mich und es gibt viele kostenlose Programme für andere Plattformen.

10
Kevin Conner

Ich folge dem Open-Source-Mantra (umschrieben) - begebe dich früh, begebe dich oft.

Grundsätzlich, wenn ich denke, dass ich nützliche Funktionen hinzugefügt habe (wie klein sie auch sein mögen), ohne dass andere Teammitglieder Probleme haben.

Diese Festschreibestrategie ist besonders in Umgebungen mit kontinuierlicher Integration nützlich, da Integrationstests mit anderen Entwicklungsbemühungen verglichen werden können, um Probleme frühzeitig zu erkennen.

10
paxdiablo

Die Faustregel, die ich verwende, ist das Einchecken, wenn die Gruppe von Dateien, die eingecheckt werden, durch einen einzelnen Eincheckkommentar abgedeckt werden kann.

Dies dient im Allgemeinen dazu, sicherzustellen, dass die Eincheckvorgänge atomar sind und die Kommentare von anderen Entwicklern problemlos verarbeitet werden können.

Dies gilt insbesondere dann, wenn sich Ihre Änderungen auf eine Konfigurationsdatei auswirken (z. B. eine Spring-Kontextdatei oder eine Struts-Konfigurationsdatei), die einen anwendungsweiten Bereich aufweist. Wenn Sie vor dem Einchecken mehrere 'Gruppen' von Änderungen vornehmen, überlappen sich deren Auswirkungen in der Konfigurationsdatei, wodurch die beiden Gruppen miteinander verschmolzen.

8
belugabob

Ich denke, Sie sollten sich nicht so viele Gedanken darüber machen, wie oft. Wichtig ist hier was, wann und warum. Zu sagen, dass Sie alle 3 Stunden oder alle 24 Stunden eine Verpflichtung eingehen müssen, macht wirklich keinen Sinn. Festschreiben, wenn Sie etwas festschreiben müssen, nicht, wenn Sie es nicht tun.

Hier ist ein Auszug aus meinem empfohlene Best Practices für die Versionskontrolle :

[...] Wenn Sie viele Änderungen gleichzeitig an einem Projekt vornehmen, teilen Sie diese in logische Teile auf und schreiben Sie sie in mehreren Sitzungen fest. Dies macht es viel einfacher, den Verlauf einzelner Änderungen zu verfolgen, was Ihnen viel Zeit spart, wenn Sie später versuchen, Fehler zu finden und zu beheben. Wenn Sie beispielsweise Feature A, B und C implementieren und Fehler 1, 2 und 3 beheben, sollte dies zu insgesamt mindestens sechs Festschreibungen führen, eine für jedes Feature und eine für jeden Fehler. Wenn Sie an einem großen Feature arbeiten oder umfangreiche Umgestaltungen vornehmen, sollten Sie Ihre Arbeit in noch kleinere Teile aufteilen und nach Abschluss jedes Teils einen Commit durchführen. Wenn Sie unabhängige Änderungen an mehreren logischen Modulen implementieren, schreiben Sie die Änderungen für jedes Modul separat fest, auch wenn sie Teil einer größeren Änderung sind.

Im Idealfall sollten Sie Ihr Büro niemals mit nicht festgeschriebenen Änderungen auf Ihrer Festplatte verlassen. Wenn Sie an Projekten arbeiten, bei denen sich Änderungen auf andere auswirken, sollten Sie eine Verzweigung verwenden, um Ihre Änderungen zu implementieren, und diese nach Abschluss wieder in den Stamm einbinden. Stellen Sie beim Festschreiben von Änderungen an Bibliotheken oder Projekten, von denen andere Projekte und damit auch andere Personen abhängig sind, sicher, dass Sie ihre Builds nicht brechen, indem Sie Code festschreiben, der nicht kompiliert werden kann. Code zu haben, der nicht kompiliert werden kann, ist jedoch keine Entschuldigung, um ein Commit zu vermeiden. Verwenden Sie stattdessen Zweige. [...]

7
Anders Sandvig

Ihr aktuelles Muster ist sinnvoll. Denken Sie daran, wie Sie verwenden diese Quellcodeverwaltung: Was ist, wenn Sie ein Rollback ausführen müssen oder ein Diff ausführen möchten? Die von Ihnen beschriebenen Chunks scheinen in diesen Fällen genau das richtige Differential zu sein: Das Diff zeigt Ihnen genau, was sich bei der Implementierung von Bug # (im Eincheckprotokoll angegeben) geändert hat, oder was der neue Code für die Implementierung einer Funktion war. In ähnlicher Weise berührt das Rollback jeweils nur eine Sache.

6
Domenic

Ich setze mich auch gerne ein, nachdem ich einen Teil meiner Arbeit beendet habe, was oft mehrmals am Tag geschieht. Ich denke, es ist einfacher zu sehen, was bei kleinen Commits passiert als bei großen. Wenn Sie über zu viele Festschreibungen besorgt sind, können Sie eine Verzweigung erstellen und diese nach Abschluss der gesamten Funktion wieder im Trunk zusammenführen.

Hier ist ein verwandter Blog-Beitrag: Coding Horror: Früh einchecken, oft einchecken

6
Mike Henry

Versuchen Sie, wie andere angegeben haben, einen logischen Block festzuschreiben, der "vollständig" genug ist, dass er nicht auf die Weise anderer Entwickler gelangt (z. B. werden automatisierte Tests erstellt und bestanden).

Jedes Entwicklerteam/Unternehmen muss für jede Branche definieren, was "vollständig genug" ist. Beispielsweise gibt es Feature-Zweige, für die der Code nur erstellt werden muss, einen Trunk, für den auch Code zum Bestehen automatisierter Tests erforderlich ist, und Beschriftungen, die angeben, dass etwas den QS-Test bestanden hat.

Ich sage nicht, dass dies ein gutes Muster ist; Ich weise nur darauf hin, dass die Vorgehensweise von den Richtlinien Ihres Teams/Unternehmens abhängt.

4
apollodude217

In dem Moment, in dem Sie darüber nachdenken.

(solange das, was Sie einchecken, sicher ist)

3
shea241

Hängt von Ihrem Quellcode-System ab und davon, was Sie noch haben. Wenn Sie Git verwenden, legen Sie fest, wann immer Sie einen Schritt beenden. Ich benutze SVN und setze mich gerne ein, wenn ich ein ganzes Feature fertiggestellt habe, also alle ein bis fünf Stunden. Wenn ich CVS verwenden würde, würde ich das gleiche tun.

3
Kevin Conner

Ich checke auch gerne regelmäßig ein. Das ist jedes Mal, wenn ich einen Schritt in Richtung meines Ziels gemacht habe.

Dies ist normalerweise alle paar Stunden.

Meine Schwierigkeit besteht darin, jemanden zu finden, der bereit und in der Lage ist, so viele Codeprüfungen durchzuführen.

Unsere Unternehmenspolitik sieht vor, dass wir eine Codeüberprüfung durchführen müssen, bevor wir etwas einchecken können, was sinnvoll ist. Es gibt jedoch nicht immer jemanden in der Abteilung, der Zeit hat, um sofort eine Codeüberprüfung durchzuführen. Mögliche Lösungen:

  1. Mehr Arbeit pro Check-In; weniger Checkins == weniger Bewertungen.
  2. Ändern Sie die Check-in-Richtlinie des Unternehmens. Wenn ich gerade etwas überarbeitet habe und die Unit-Tests alle grün laufen, kann ich die Regel vielleicht lockern?
  3. Bewahren Sie die Änderung auf, bis jemand die Überprüfung durchführen und weiterarbeiten kann. Dies kann problematisch sein, wenn der Prüfer Ihren Code nicht mag und Sie neu entwerfen müssen. Das Jonglieren verschiedener Phasen einer Aufgabe, indem Änderungen „zurückgestellt“ werden, kann chaotisch werden.
3
GarethOwen

Ich stimme einigen der Antworten zu: Checke keinen Code ein, der nicht kompiliert werden kann; Verwenden Sie eine persönliche Filiale oder ein persönliches Repository, wenn Ihr Anliegen eine "Sicherung" des Codes oder seiner Änderungen ist. Checken Sie ein, wenn die logischen Einheiten vollständig sind.

Eine andere Sache, die ich hinzufügen möchte, ist, dass die Check-in-Rate je nach Ihrer Umgebung mit der Zeit variieren kann. Zum Beispiel ist es sicherheits- und revisionssicher, früh in einem Projekt einzuchecken, nachdem jedes funktionale Teil einer Komponente fertig ist (ich denke an Fälle, in denen frühere Teile überarbeitet werden, während spätere entwickelt werden). Später im Projekt wird dagegen die vollständige Funktionalität wichtiger, insbesondere während der Entwicklung/des Testens der Integration. Eine halbe Integration oder ein halber Fix hilft niemandem.

Was das Einchecken nach jeder Fehlerbehebung angeht: Es sei denn, die Behebung ist trivial, absolut! Nichts ist schmerzhafter als festzustellen, dass ein Check-in drei Fehlerbehebungen enthielt und eine davon rückgängig gemacht werden muss. In der Regel hat der Entwickler in dieser Situation drei Fehler in einem Bereich behoben und festgestellt, welche Änderung für welche Fehlerbehebung ein Albtraum ist.

3
DocMax

Ich möchte Änderungen alle 30-60 Minuten vornehmen, solange diese sauber kompiliert werden und es keine Regressionen bei Unit-Tests gibt.

2
TraumaPony

Wenn Sie an einem Zweig arbeiten, der nicht freigegeben wird, ist ein Commit immer sicher.

Wenn Sie es jedoch mit anderen Entwicklern teilen, ist das Festschreiben von nicht funktionierendem Code wahrscheinlich etwas ärgerlich (insbesondere, wenn es sich an einem wichtigen Ort befindet). Normalerweise gebe ich nur Code ein, der effektiv "funktioniert" - nicht, dass er vollständig getestet wurde, sondern dass ich festgestellt habe, dass er tatsächlich kompiliert und nicht sofort fehlschlägt.

Wenn Sie einen integrierten Bug-Tracker verwenden, kann es hilfreich sein, separate Festschreibungen vorzunehmen, wenn Sie zwei Fehler behoben haben, damit das Festschreibungsprotokoll gegen die richtigen Fehler gerichtet werden kann. Aber manchmal behebt eine Codeänderung zwei Fehler, sodass Sie nur noch auswählen müssen, gegen welche es sich richten soll (es sei denn, Ihr System lässt zu, dass ein Commit mehreren Fehlern zugeordnet wird).

2
MarkR

Nun, Sie könnten einen eigenen Zweig haben, dem Sie so oft Sie möchten zuweisen können, und wenn Sie mit Ihrem Feature fertig sind, können Sie es zum Haupt-Trunk zusammenführen.

In Bezug auf die Häufigkeit von Commits überlege ich, wie schmerzhaft es für mich wäre, wenn meine Festplatte abstürzen würde und ich nichts festgeschrieben hätte - die Quantität dieses Etwas für mich beträgt ungefähr 2 Stunden Arbeit.

Natürlich lege ich niemals etwas fest, das nicht kompiliert werden kann.

2
Vaibhav

Mindestens einmal am Tag.

2
Hamish Smith

Ich habe kein bestimmtes Zeitlimit pro Festschreibung, ich tendiere dazu, eine Festschreibung zu machen, sobald ein Test bestanden ist, und ich bin mit dem Code zufrieden. Ich würde keinen Code festschreiben, der nicht kompiliert wird oder sich auf andere Weise in einem Zustand befindet, auf den ich bei einem Fehler nicht zurückgreifen kann

2
Crippledsmurf

Ich glaube immer noch an die Redewendung "begebe oft, begebe früh". Ich bevorzuge dezentrale VCS wie Mercurial und es ist kein Problem, mehrere Dinge zu begehen und sie später in den Upstream zu verschieben.

Dies ist wirklich eine häufige Frage, aber die eigentliche Frage lautet: Können Sie unvollendeten Code schreiben?

2
unexist

Sie müssen den Kompromiss zwischen Sicherheit und Wiederherstellbarkeit einerseits und einfacher Änderungsverwaltung andererseits für das gesamte Projekt ausbalancieren.

Das beste Schema, das ich verwendet habe, hatte zwei Antworten auf diese Frage.

Wir haben 2 völlig getrennte Repositorys verwendet: eines war das projektweite Repository und das andere war unser eigenes persönliches Repository (wir haben zu der Zeit rcs verwendet).

Wir haben sehr regelmäßig in unser persönliches Repository eingecheckt, so ziemlich jedes Mal, wenn Sie Ihre geöffneten Dateien gespeichert haben. Als solches war das persönliche Repository im Grunde genommen ein großer, weitreichender Rückgängig-Puffer.

Sobald wir einen Code-Block hatten, der kompiliert, in Ordnung getestet und als allgemein einsatzbereit akzeptiert wurde, wurde er in das Projekt-Repository eingecheckt.

Leider war dieses System auf die Verwendung unterschiedlicher VCS-Technologien angewiesen, um funktionsfähig zu sein. Ich habe keine zufriedenstellende Methode gefunden, um dieselben Ergebnisse mit zwei VCS desselben Typs zu erzielen (z. B. zwei Subversion-Repositorys).

Ich habe jedoch akzeptable Ergebnisse erzielt, indem ich "persönliche" Entwicklungszweige in einem Subversion-Repository erstellt habe - regelmäßig in den Zweig eingecheckt und dann nach Abschluss in den Stamm eingegliedert.

2

Wann immer Sie einen Code fertig stellen, der funktioniert und keinen anderen vermasselt, wenn er in einem Update veröffentlicht wird.

Und bitte stellen Sie sicher, dass Sie richtig kommentieren.

2
Andy Lester