Wann ist ein Versionskontroll-Commit zu groß? [geschlossen]

Ich habe an mehreren Stellen gehört, dass "keine großen Commits" gemacht werden, aber ich habe nie verstanden, was "große" Commits sind. Ist es groß, wenn Sie an einer Reihe von Dateien arbeiten, auch wenn diese verwandt sind? An wie vielen Teilen eines Projekts sollten Sie gleichzeitig arbeiten?

Für mich fällt es mir schwer, "kleine Verpflichtungen" einzugehen, da ich etwas vergesse oder erschaffe, das etwas anderes erschafft, das etwas anderes erschafft. Sie haben dann folgendes Ergebnis:

Ausgehende Warteschlange angepasst

Bot
-Neues Feld msgQueue, das nichts anderes als ein SingleThreadExecutor ist
-sendMsg blockiert, bis die Nachricht gesendet wird, und fügt eine Wartezeit zwischen dem Empfang der Nachrichten hinzu
geschickt
-adminExist-Aufrufe aktualisiert (siehe Controller)
- Entfernte Aufrufe von sendMessage

Regler
-Neues Feld msgWait gibt die Wartezeit zwischen Nachrichten an
- Das Starten von Service-Plugins wurde nach reloadPlugins verschoben
-adminExists wurde wegen globaler Administratoren vom Server verschoben. Schecks am Kanal,
Server und globaler Ebene

Administrator
-Neue Methoden getServer und getChannel, die das entsprechende Objekt Admin erhalten
gehört

BotEvent
-toString () zeigt auch extra und extra1

Kanal
-Kanalfeld in Name umbenannt
- Tippfehler im Kanal (int) behoben

Server
- adminExists zum Controller verschoben

PluginExecutor
- Kleinere Tests hinzugefügt, werden später entfernt

JS-Plugins
-Aktualisiert auf Rahmenänderungen
-Ersetzte InstanceTracker.getController () mit Controller.instance
-VLC rede jetzt in eigener Datei

Verschiedene NB-Projektaktualisierungen und -änderungen

---

Betroffene Dateien
Ändern Sie /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Ändern Sie /trunk/Quackbot-Core/dist/README.TXT
Ändern Sie /trunk/Quackbot-Core/nbproject/private/private.properties
Ändern Sie /trunk/Quackbot-Core/nbproject/private/private.xml
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/Bot.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/Controller.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Ändern Sie /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Ändern Sie /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Ändern Sie /trunk/Quackbot-GUI/dist/README.TXT
Ändern Sie /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Ändern Sie /trunk/Quackbot-GUI/nbproject/private/private.properties
Ändern Sie /trunk/Quackbot-GUI/nbproject/private/private.xml
Ändern Sie /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Ändern Sie /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Löschen Sie /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Ändern Sie /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Ändern Sie /trunk/Quackbot-Impl/dist/README.TXT
Ändern Sie /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Ändern Sie /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Ändern Sie /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Ändern Sie /trunk/Quackbot-Impl/lib/javarebel.stats
Fügen Sie /trunk/Quackbot-Impl/lib/jrebel.info hinzu
Ändern Sie /trunk/Quackbot-Impl/nbproject/private/private.properties
Ändern Sie /trunk/Quackbot-Impl/nbproject/private/private.xml
Ändern Sie /trunk/Quackbot-Impl/nbproject/project.properties
Ändern Sie /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Add / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Ändern Sie /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Ändern Sie /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Ändern Sie /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Ändern Sie /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Ändern Sie /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Ändern Sie /trunk/Quackbot-Impl/plugins/testCase.js
Fügen Sie /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js hinzu
Ändern Sie /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Fügen Sie / trunk / Quackbot-Impl / vlc_http hinzu
Fügen Sie /trunk/Quackbot-Impl/vlc_http/current.html hinzu
Ändern Sie /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Ändern Sie /trunk/Quackbot-Plugins/dist/README.TXT
Ändern Sie /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Ändern Sie /trunk/Quackbot-Plugins/nbproject/private/private.properties
Ändern Sie /trunk/Quackbot-Plugins/nbproject/private/private.xml
Ändern Sie /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Füge / trunk / Quackbot-Plugins / vlc_http hinzu
Fügen Sie /trunk/global-lib/jrebel.jar hinzu

Ja....

Also für Fragen:

• Was sind einige Faktoren, wenn ein Commit zu groß wird ( nicht offensichtliches Zeug )?
• Wie können Sie solche Commits verhindern? Bitte machen Sie nähere Angaben
• Was ist, wenn Sie sich in einem frühen Entwicklungsstadium befinden, in dem sich die Dinge schnell bewegen? Sind riesige Commits noch in Ordnung?

Für mich fällt es mir schwer, "kleine Verpflichtungen" einzugehen, da ich etwas vergesse oder erschaffe, das etwas anderes erschafft, das etwas anderes erschafft.

Das ist ein Problem. Es hört sich so an, als müssten Sie lernen , Ihre Arbeit in kleinere, handlichere Teile aufzuteilen.

Das Problem bei großen Commits sind:

• In einem Projekt mit mehreren Personen führt eine höhere Wahrscheinlichkeit, dass Ihre Commits ausgeführt werden, dazu, dass andere Entwickler Konflikte lösen.
• Es ist schwieriger, genau zu beschreiben, was in Protokollnachrichten getan wurde.
• Es ist schwieriger, die Reihenfolge zu verfolgen, in der Änderungen vorgenommen wurden, und daher die Ursache von Problemen zu verstehen.
• Es erhöht die Wahrscheinlichkeit, viele nicht festgelegte Arbeiten zu verlieren.

Manchmal sind große Commits unvermeidlich. zB wenn Sie eine Haupt-API ändern müssen. Das ist aber normalerweise nicht der Fall. Und wenn Sie sich in dieser Situation befinden, ist es wahrscheinlich eine gute Idee, eine Zweigstelle zu erstellen und Ihre Arbeit dort zu erledigen ... mit vielen kleinen Aufgaben ... und sich wieder zu integrieren, wenn Sie fertig sind.

(Ein anderer Fall ist, wenn Sie einen ersten Import durchführen, dies ist jedoch aus der Sicht der oben aufgeführten Probleme NICHT problematisch.)

Das Prinzip der Einzelverantwortung.

Jedes Versionskontroll-Commit sollte nur einem Zweck dienen. Wenn Sie das Wort "und" oder "auch" in Ihre Zusammenfassung aufnehmen müssen, müssen Sie es aufteilen.

Es kommt sehr häufig vor, dass in Ihrer Arbeitskopie viele separate, nicht oder nur teilweise zusammenhängende Änderungen vorgenommen werden. Dies wird als "Wirrwarr von Arbeitskopien" bezeichnet und ist selbst für disziplinierte Entwickler sehr schwer zu vermeiden. Git und Mercurial bieten Ihnen jedoch beide Tools, um das Problem zu beheben - git add -p oder chunk selection und Mercurial Queues in TortoiseHg .

Stellen Sie sich vor, der Kunde möchte eine bestimmte Änderung vornehmen lassen - zum Beispiel, um eine Regel hinzuzufügen, dass etwas nicht innerhalb von zwei Tagen nach dem "Was auch immer" -Datum getan werden kann. Dann, nachdem Sie die Änderung vorgenommen haben, ändern sie ihre Meinung. Sie möchten Ihr Commit zurücksetzen. Wenn es nur darum geht, die Sortierreihenfolge von unabhängigen Berichten zu ändern, ist Ihr Leben ein Elend.

Ein Arbeitselement, ein Änderungssatz. Eine Anfrage vom Client, ein Änderungsset. Eine Sache, über die Sie Ihre Meinung ändern könnten, ein Änderungsset. Manchmal bedeutet dies, dass es sich um eine einzelne Codezeile handelt. Manchmal sind es zehn verschiedene Dateien, einschließlich des Datenbankschemas. Das ist gut.

Große Einsätze sind, wenn Sie Tonnen von Änderungen haben, die nicht wirklich alle in den gleichen Eimer gehen. Wenn ich die Controller-Logik ändere, dann das Datenbank-Verbindungsmodell, dann einiges anderes. Skripte, ich sollte nicht alles unter einem Commit bündeln.

Prävention macht Commits entsprechend dem, was Sie erledigen. Im obigen Beispiel würde ich nach der Controller-Logik, nach der Datenbankarbeit und nach den Skripten ein Commit ausführen. Legen Sie sich nicht ab, nur weil Sie wissen, was sich geändert hat. Andere Leute werden auf Ihre Commit-Log-Meldung "Geänderte Inhalte" zurückblicken und sich fragen, was Sie geraucht haben.

Anfängliche Importe sind wahrscheinlich die größten Verpflichtungen, die Sie jemals haben sollten. Ein System von Grund auf neu einrichten? Sicher haben ein paar große Verpflichtungen. Nachdem Sie es ausgeglichen haben, ist es Zeit, die Dinge zu organisieren.

Wenn Sie wissen, dass Sie vorher an einem großen Codeabschnitt arbeiten werden, empfehle ich Ihnen, einen Zweig für Ihr spezielles Feature zu erstellen, während Sie regelmäßig Code von der Hauptzeile abrufen, um sicherzustellen, dass Ihr Code synchron bleibt. Wenn Sie mit der Arbeit am Zweig fertig sind, führen Sie alle Änderungen wieder in der Hauptzeile zusammen. Auf diese Weise werden andere Teammitglieder nicht überrascht und / oder verärgert sein, wenn sie ein großes Engagement sehen. Außerdem ist die Wahrscheinlichkeit, dass etwas kaputt geht, viel geringer. Üben Sie weiter, um die Dinge in kleinere Commits aufzuteilen. Mit der Zeit wird es zur zweiten Natur.

Dieses Beispiel zeigt ein zu großes Commit.

Beschreiben Sie als Faustregel die Änderung in einem Satz oder einer Textzeile. (Basierend auf dieser Regel sollte das Commit in 10-15 kleinere unterteilt werden.) Wenn Sie ein Commit in einer Zeile nicht ausreichend kommentieren können, ist es bereits zu groß.

Notieren Sie sich in Ihrem Notizblock (oder in Notepad), was Sie bereits geändert oder hinzugefügt haben, um kleinere Commits zu üben. Festschreiben, bevor es eine lange Liste wird oder bevor Sie eine Codeänderung vornehmen, die nichts mit dem zu tun hat, was Sie bereits im Notizblock haben.

In meinem Bereich (Physikmodellierung) stelle ich heute einen Fehler in der Ausgabe fest, der seit 6 Monaten nicht mehr im Repository vorhanden war. In diesem Fall werde ich eine binäre Suche nach Revisionen durchführen:

1. Laufmodell von vor 3 Monaten
2. Wenn der Fehler weiterhin ausgegeben wird, führen Sie das Modell von vor 4,5 Monaten aus
3. ... wiederholen, bis ich das Commit finde, das zu einer schlechten Ausgabe führt

Als der Fehler in einem monströsen Commit eingeführt wurde, muss ich mich mit einem feinen Kamm hinsetzen, um die Ursache des Problems zu finden. Wenn das Commit eine kleine Anzahl von Dateien berührt hat, ist es weniger schmerzhaft, die Codezeile (n) aufzuspüren, die das Problem verursacht hat.

Ich würde empfehlen, Ihr Problem in eine Reihe kleinerer Aufgaben zu unterteilen (im Idealfall jede Aufgabe in einen Bug-Tracker stellen). Machen Sie ein Commit, wenn Sie jede Aufgabe erledigen (und schließen Sie diesen Fehler / diese Funktion in Ihrem Bug-Tracker).

Es ist nicht die Größe des Commits, die wirklich wichtig ist, sondern der Umfang der Änderung, der bestimmen sollte, wie Ihre Commits organisiert sind.

Sie können beispielsweise jede Instanz von __macro1to __macro2in einer großen Codebasis ändern , die 200 Dateien ändert. 200 Verpflichtungen wären in diesem Fall nicht vernünftig.

Was Sie am Ende haben möchten, ist die Möglichkeit, das Repository bei jeder einzelnen Revision abzurufen und die Build-Arbeit zu veranlassen. Haben Sie von libfoonach libbargewechselt? Ich hoffe, dass diese Änderung auch das Aktualisieren Ihrer Build-Skripte und Makefiles (oder was auch immer anwendbar ist) beinhaltet.

Manchmal müssen Sie möglicherweise eine Reihe von experimentellen Änderungen vornehmen, um eines zu erreichen. In diesem Fall müssen Sie bestimmen, welcher Bereich für Sie wichtiger ist, wenn Sie später zurücksetzen müssen. Hängt einer vom anderen ab? Übernehmen Sie sie alle auf einmal in einer einzigen Revision. Andernfalls würde ich in diesem Fall ein Commit pro Änderung vorschlagen. Sie sollten sowas sowieso in einer anderen Filiale oder in einem anderen Repo machen.

Ja, Sie haben die Möglichkeit, eine einzelne Datei auf eine vorherige Revision zurückzusetzen (und damit eine Datei aus einer größeren Verpflichtung heraus zu sichern). Auf diese Weise werden Tools wie die Zweiteilung später im Verlauf wirklich durcheinander gebracht und der Verlauf verschmutzt.

Wenn du anhältst und denkst "Ok, Tests bestehen, ich denke das funktioniert. Aber wenn es schlecht läuft, kann ich es einfach wieder rausholen?" .. Sie werden vernünftige Verpflichtungen eingehen.

Die Sache, die hier zu verstehen ist, ist, dass "groß" in diesem Zusammenhang die Anzahl der deutlichen Änderungen betrifft, nicht die physische Größe des Commits (obwohl die beiden im Allgemeinen Hand in Hand gehen werden).

Es ist nicht so eine Frage von „nicht groß Commits machen“ , wie er tut kleine Commits machen - das ideal zu begehen kleine Selbst zu sein enthaltenen Änderungen.

Aus dem Changelog geht hervor, dass Sie eine Reihe von Dingen haben, die separat (und sicher) ausgeführt werden könnten, und daher ist es ziemlich offensichtlich, dass sie zu groß sind.

Der Grund, warum dies ein Problem sein kann, ist, dass Ihr letzter Commit Ihr Bezugspunkt für die Änderungen ist, die Sie gerade vornehmen. Wenn Sie beispielsweise das erste Bit richtig und das nächste Bit falsch machen, ist dies kein einfacher Weg um Ihre Arbeit an den Punkt zurückzuführen, an dem Sie Fehler gemacht haben (BTDTGTTS).

Natürlich sind Änderungen manchmal nur groß - Refactoring in großem Maßstab - und wie von anderen vorgeschlagen, müssen Sie auf diese Weise verzweigen, auch wenn Ihre einzelnen Commits möglicherweise Dinge beschädigen, die vom Hauptentwicklungsstamm getrennt sind, sodass dies kein Problem darstellt Problem und Sie erhalten weiterhin früh und oft zu verpflichten.

Eine weitere Sache: Wenn sich während Ihrer Arbeit etwas ereignet, das eine schnellere Bearbeitung erfordert, müssen Sie es separat ändern (idealerweise in einem vollständig unterschiedlichen Satz von Ordnern) und separat festschreiben.

Die eigentliche Herausforderung bei all dem ist nicht die Mechanik, sondern die Denkweise - dass ein Commit nicht nur eine Sicherungskopie ist, die Sie hin und wieder erstellen, sondern dass jedes Commit ein Zoll-Kieselstein auf dem Weg ist und dass es nichts auszusetzen gibt von kleinen Commits und dem Mischen verschiedener Dinge in einem Mob-Commit ist genauso schlimm wie das Mischen vage verwandter Teile der Funktionalität in einem Stück Code.

Trainieren Sie sich zumindest so, dass Sie sich verpflichten, wann immer Sie sich denken: "Ich mag meine bisherigen Fortschritte und ich möchte sie nicht verlieren, wenn die Änderungen, die ich vornehmen werde, eine Katastrophe sind." Dann haben Sie die Möglichkeit, das VCS zu nutzen, um alle von Ihnen ausprobierten Sackgassen oder speziellen Debugging-Code, den Sie hinzugefügt haben, um ein Problem aufzuspüren, zu beseitigen. (zB mit git reset --hardoder rm -rf *; svn update)

Es gibt keine feste Regel, keine Trennlinie, an der Ihr Commit zu groß ist.

Es gibt jedoch eine Richtlinie, die besagt, dass kleinere Festschreibungen im Rahmen des Zumutbaren besser sind (dh, das Festschreiben jeder Zeile ist wahrscheinlich übertrieben).

Ich behalte diese Art von Richtlinien im Hinterkopf:

• Ein einzelnes Commit sollte Änderungen für nur eine Fehlerbehebung enthalten
• Ein einzelnes Commit sollte nicht mehr als einen halben Arbeitstag umfassen
• Ein einzelnes Commit sollte den Build nicht unterbrechen

Natürlich - daran denke ich - YMMV. Verschiedene Entwickler bevorzugen unterschiedliche Granularitätsstufen.

Je kleiner der Commit ist, desto einfacher ist es, genau zu finden, woher eine potenzielle Regression kommt.

Im Idealfall sollte ein Commit atomar sein , im Sinne der kleinsten zusammenhängenden Änderung an der Codebasis (im Zusammenhang mit einem Fehler, einer Funktion usw.).

Spezifische Tipps, um die Größe des Commits klein zu halten, hängen in hohem Maße von Ihrem VCS und dessen Einrichtung ab: Sie müssen in der Lage sein, lokal ein Commit durchzuführen oder in Ihrer eigenen Filiale auf dem Server zu arbeiten.

Der Schlüssel besteht darin, jedes Mal, wenn Sie eine atomare Änderung vornehmen, einen Commit für Ihren "privaten" Zweig durchzuführen. Anschließend können Sie Ihren Zweig beispielsweise wöchentlich regelmäßig zusammenführen.

Mit einem dvcs könnte Ihr Workflow so aussehen:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Verwenden eines zentralisierten vcs:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Sie haben wahrscheinlich das Sprichwort gehört, dass Perfektion ist, wenn Sie nichts mehr wegnehmen können. Das sollte auch Ihren Standard für die Festschreibungsgröße beschreiben.

Es hängt von Ihrem Projekt ab, wo diese "perfekte" Größe ist. Wenn Sie an externe Kunden versenden, ist eine gute Größe möglicherweise die kleinste Stufe, die Sie für den Versand benötigen, wenn Sie die nächste nicht rechtzeitig abschließen. Wenn Sie interne, häufig bereitgestellte Anwendungen erstellen, ist die beste Größe möglicherweise das kleinste Inkrement, das nichts zerstört (und Sie näher ans Ziel bringt).

Moderne Versionskontrollsysteme helfen Ihnen dabei, gute Commits zu erstellen, indem sie einfach verzweigen, interaktiv umbasieren, Bereiche bereitstellen usw.

Commit-Nachrichten sollten nur aus einer Zeile bestehen (und für git maximal 60 Zeichen). Die Menge des festgeschriebenen Codes muss klein genug sein, um die beschreibende Nachricht innerhalb dieser Grenze zu halten.

Ich tendiere dazu, mich jedes Mal zu verpflichten (umso mehr, als wir jetzt zu git gewechselt sind), wenn ich einen Teil erledigt habe, um zu erfassen, warum die Dinge auf diese Weise erledigt wurden.

Manchmal haben Sie den ganzen Tag an verschiedenen logisch unterschiedlichen Chagnes gearbeitet und vergessen, Ihren Code dazwischen zu schreiben. Die Verwendung von git citoolkann sehr hilfreich sein, um Ihre Arbeit am Ende des Tages in schöne mundgerechte Stücke aufzuteilen, selbst wenn Sie tagsüber während der Arbeit nicht so vorsichtig waren.

git citool Mit dieser Option können Sie auswählen, welche bestimmten Hunks einer Datei (oder welche bestimmten Zeilen) in einem bestimmten Commit festgeschrieben werden sollen, damit Sie (nicht überlappende) Änderungen, die an derselben Datei vorgenommen wurden, in mehrere Commits aufteilen können.

(Es scheint, dass Sie Subversion verwenden. Ich kenne kein Tool, das dies für Subversion tut, aber Sie könnten die Verwendung git-svndes Subversion-Adapters für Git untersuchen, der Ihr Leben verändern wird.)

Je höher der Commit, desto wahrscheinlicher ist es, dass Sie den Build abbrechen und vom Rest Ihres Teams bezahlt werden. Ich versuche, zweimal täglich Änderungen vorzunehmen. Kurz vor dem Mittagessen und bevor ich nach Hause gehe. Also versuche ich um 12 Uhr und 16.30 Uhr, alles zum Laufen zu bringen und bereit zu machen, etwas zu tun. Ich finde, dass diese Praxis für mich funktioniert.

Um Ihre Fragen zu beantworten:

1) Für mich wird das Standard-Commit als groß angesehen, wenn es mehr als eine Sache tut. Damit meine ich, einen Fehler zu beheben oder eine Funktion hinzuzufügen.

2) Verhindern Sie solche Commits, indem Sie es sich zur Gewohnheit und Regel machen, sich immer dann zu verpflichten, wenn Sie etwas erledigen.

3) In den frühen Entwicklungsstadien erlaube ich den Commits, die erste Erstellung der Dateien einzubeziehen, die später verwendet werden.

Ich möchte darauf hinweisen, dass mit "fertig" gemeint ist, dass alle von Ihnen identifizierten Fehler behoben wurden und Sie den Build nicht durch Festschreiben brechen können.

Ja, dies generiert eine große Anzahl von Commits, aber Sie können damit genau das zurücksetzen, was die Dinge kaputt gemacht hat, anstatt eine große Reihe von Änderungen rückgängig machen zu müssen, die gleichzeitig festgeschrieben wurden, wenn nur eine der Änderungen ein Problem verursacht.

Ich möchte auch darauf hinweisen, dass sich die Regeln für verteilte Versionskontrollsysteme (DVCS) wie Mercurial und Git etwas ändern. In dem Fall, dass Sie eine dieser Optionen verwenden, übernehmen Sie das Commit, wenn Sie eine Änderung vorgenommen haben, diese aber noch nicht getestet haben, und verschieben Sie sie dann in das zentrale Repository, wenn sie funktioniert. Dies ist vorzuziehen, da Sie so mehr Änderungen an Ihrem Code vornehmen können, ohne sich Gedanken über das Unterbrechen des Builds machen zu müssen.

In meinem Fall versuche ich, Dateien eines Servers an das Repository-System (SVN) zu übertragen. Dies ist die erste Festschreibung und ich möchte sie nicht herunterladen, da es sich um ein sehr großes Projekt handelt (ein paar GB) und ich möchte die erste Festschreibung vom Client-Server ausführen.

Das Problem ist, dass sich der Client auf einem gemeinsam genutzten Server befindet und der svn-Client (oder eine andere Software) beendet wird, wenn er länger als eine Minute ausgeführt wird.

Eine Alternative wäre, das Projekt auf meinen Computer herunterzuladen und von dort aus den ersten Commit durchzuführen. Ich bin jedoch daran interessiert, ob es in SVN eine Option gibt, den großen Commit in weitere zu unterteilen, ähnlich wie bei Transaktionsmethoden.

Der Entwickler vor mir hat noch nie ein Versionskontrollsystem verwendet.

Das Unternehmen, für das ich arbeite, erzwingt eine Überprüfung des Peer-Codes für jedes Commit. Daher ist jedes Commit, das es einem Peer erschwert, in angemessener Zeit herauszufinden, was vor sich geht und zu überprüfen, zu umfangreich.