it-swarm-eu.dev

Wann ist ein Versionskontroll-Commit zu groß?

Ich habe an mehreren Stellen gehört, dass "keine großen Commits machen", aber ich habe nie verstanden, was ein "großer" Commit ist. 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 habe ich Probleme beim Versuch, "kleine Commits" zu machen, da ich etwas vergesse oder erschaffe, das etwas anderes schafft, das etwas anderes schafft. Sie erhalten dann Dinge wie diese:

 Benutzerdefinierte ausgehende Warteschlange 
 
 Bot 
 - Neues Feld msgQueue, das nichts anderes als ein SingleThreadExecutor ist 
 - sendMsg blockiert, bis eine Nachricht gesendet wird, und Fügt Wartezeiten zwischen dem Senden von Nachrichten 
 hinzu. 
 - adminExist-Aufrufe aktualisiert (siehe Controller) 
 - Aufrufe an sendMessage 
 
 Controller 
 -Neues Feld msgWait gibt die Wartezeit zwischen Nachrichten an 
 - Start von Service-Plugins, die nach reloadPlugins verschoben wurden 
 - adminExists wurden aufgrund globaler Administratoren vom Server verschoben. Überprüft auf Kanal-, 
 Server- und globaler Ebene 
 
 Admin 
 - Neue Methoden getServer und getChannel, zu denen das entsprechende Objekt gehört, zu dem Admin 
 Gehört 
 
 BotEvent 
 - toString () zeigt auch extra und extra1 
 
 Kanal 
 - Kanalfeld umbenannt in Name 
 - Tippfehler in Kanal (int) behoben. 
 
 Server 
 - adminExists auf Controller verschoben. 
 
 PluginExecutor 
 - Kleinere Tests hinzugefügt, wird später entfernt 
 
 JS-Plugins 
 - Aktualisiert auf Framework-Änderungen 
 - InstanceTracker.getController () durch Controller.instance 
 ersetzt - VLC-Talk jetzt in eigener Datei 
 
 Verschiedene NB Projektaktualisierungen und -änderungen 
 
 --- 
 
 Betroffene Dateien 
 Ändern /trunk/Quackbot-Core/dist/Quackbot-Core.jar[.____.‹Modify /trunk/Quackbot-Core/dist/README.TXT[.____.‹Modify /trunk/Quackbot-Core/nbproject/private/private.properties[.____.‹Modify/trunk/Quackbot-Core/nbproject/p rivate/private.xml 
 Ändern Sie /trunk/Quackbot-Core/src/Quackbot/Bot.Java[.____.‹Modify /trunk/Quackbot-Core/src/Quackbot/Controller.Java
 Ändern Sie /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.Java[.____.‹Modify /trunk/Quackbot-Core/src/Quackbot/info/Admin.Java[.____.‹Modify/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.Java 
 Ändern Sie /trunk/Quackbot-Core/src/Quackbot/info/Channel.Java[.____.‹Modify/trunk/Quackbot-Core/src/Quackbot/info/Server.Java 
 Ändern /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar[.____..Modify /trunk/Quackbot-GUI/dist/README.TXT[.____.‹Modify/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar 
 Ändern Sie /trunk/Quackbot-GUI/nbproject/private/private.properties[.____.‹Modify/trunk/Quackbot-GUI/nbproject/private/private.xml 
 Ändern Sie /trunk/Quackbot-GUI/src/Quackbot/GUI.Java
Modify /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.Java
 Löschen Sie /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.Java[.____.‹Modify/t runk/Quackbot-Impl/dist/Quackbot-Impl.jar 
 Ändern Sie /trunk/Quackbot-Impl/dist/README.TXT[.____.‹Modify/trunk/Quackbot-Impl/dist/lib/Quackbot- Core.jar 
 Ändern Sie /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar[.____.‹Modify /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
 Ändern Sie /trunk/Quackbot-Impl/lib/javarebel.stats[.____.‹Add /trunk/Quackbot-Impl/lib/jrebel.info[.____.‹Modify/trunk/Quackbot-Impl/nbproject/private/private.properties 
 Ändern Sie /trunk/Quackbot-Impl/nbproject/private/private.xml[.____.‹Modify /trunk/Quackbot-Impl/nbproject/project.properties[.____.‹Modify/trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js 
 Fügen Sie /trunk/Quackbot-Impl/plugins/CMDs/Operator/hostBan[.____.‹Modify/trunk/Quackbot-Impl/plugins/CMDs/hinzu Operator/mute.js 
 Ändern Sie /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js[.____.‹Modify /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[.____.‹Modify /trunk/Quackbot-Impl/plugins/testCase.js[.____.‹Add/trunk/Quackbot-Impl/plugins /utils/whatsPlaying.js[.____.‹Modify /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.Java[.____.‹Add /trunk/Quackbot-Impl/vlc_http[.____.‹Add/trunk /Quackbot-Impl/vlc_http/current.html[.____.‹Modify /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar[.____.‹Modify /trunk/Quackbot-Plugins/dist/README.TXT 
 Ändern Sie /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar[.____.‹Modify /trunk/Quackbot-Plugins/nbproject/private/private.properties[.____.‹Modify/trunk/Quackbot -Plugins/nbproject/private/private.xml 
 Ändern Sie /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.Java[.____.‹Add /trunk/Quackbot-Plugins/vlc_http
 Füge /trunk/global-lib/jrebel.jar[.____ hinzu.]

Ja....

Also bei Fragen:

  • Was sind einige Faktoren, wenn ein Commit zu groß wird (nicht offensichtliches Zeug)?
  • Wie können Sie solche Commits verhindern? Bitte geben Sie Einzelheiten an
  • Was ist, wenn Sie sich in einem frühen Entwicklungsstadium befinden, in dem sich die Dinge schnell bewegen? Sind große Commits noch in Ordnung?
67
TheLQ

Für mich habe ich Probleme beim Versuch, "kleine Commits" zu machen, da ich etwas vergesse oder erschaffe, das etwas anderes schafft, das etwas anderes schafft.

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

Das Problem bei großen Commits sind:

  • In einem Projekt mit mehreren Personen führt eine größere Wahrscheinlichkeit, dass Ihre Commits zu Konflikten für andere Entwickler führen, zu einer Lösung.
  • 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, viel unverbindliche Arbeit zu verlieren.

Manchmal sind große Commits unvermeidlich. z.B. wenn Sie eine Haupt-API ändern müssen. Aber das ist normalerweise nicht der Fall. Und wenn Sie sich in dieser Situation befinden, ist es wahrscheinlich eine gute Idee, eine Niederlassung zu gründen und Ihre Arbeit dort zu erledigen ... mit vielen kleinen Verpflichtungen ... und sich wieder zu integrieren, wenn Sie fertig sind.

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

68
Stephen C

Das Prinzip der Einzelverantwortung.

Jedes Commit für die Quellcodeverwaltung sollte nur einem Zweck dienen. Wenn Sie das Wort "und" oder "auch" in Ihre Zusammenfassung einfügen müssen, müssen Sie es aufteilen.

Es kommt sehr häufig vor, dass Ihre Arbeitskopie viele separate, nicht zusammenhängende oder halbbezogene Änderungen enthält. Dies wird als "Problem der verwickelten Arbeitskopien" bezeichnet und ist selbst für disziplinierte Entwickler sehr schwer zu vermeiden. Git und Mercurial bieten Ihnen jedoch beide Tools zum Auflösen - git add -p oder Blockauswahl und Mercurial Queues in TortoiseHg .

40
jammycakes

Stellen Sie sich vor, der Kunde möchte eine bestimmte Änderung vornehmen lassen - beispielsweise um eine Regel hinzuzufügen, dass etwas nicht innerhalb von zwei Tagen nach dem "was auch immer" -Datum ausgeführt werden kann. 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 Berichten ohne Bezug zu ändern, ist Ihr Leben ein Elend.

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

26
Kate Gregory

Große Commits sind, wenn Sie Tonnen von Änderungen haben, die nicht wirklich alle in den gleichen Bereich fallen. Wenn ich die Controller-Logik ändere, dann das Datenbankverbindungsmodell, dann etwas anderes. Skripte, ich sollte nicht alles unter einem Commit bündeln.

Bei der Prävention werden Commits entsprechend Ihren Aufgaben vorgenommen. Im obigen Beispiel würde ich nach der Controller-Logik, nach der Datenbankarbeit und nach den Skripten festschreiben. Verschieben Sie das Commit nicht einfach, weil Sie wissen, was sich geändert hat. Andere Leute werden auf Ihre "Geänderte Sachen" Commit-Protokollnachricht zurückblicken und sich fragen, was Sie geraucht haben.

Erstimporte 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 organisiert zu halten.

10
Josh K

Wenn Sie wissen, dass Sie vorher an einem großen Codeabschnitt arbeiten werden, würde ich empfehlen, einen Zweig für Ihre spezifische Funktion zu erstellen, während Sie den Code regelmäßig von der Hauptzeile abrufen, um sicherzustellen, dass Ihr Code synchron bleibt. Wenn Sie mit der Arbeit am Zweig fertig sind, führen Sie alle Ihre Ä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 besteht eine viel geringere Wahrscheinlichkeit, dass Dinge kaputt gehen. Übe weiter, um die Dinge in kleinere Commits aufzuteilen. Mit der Zeit wird es zur zweiten Natur.

7
ysolik

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 Commits unterteilt werden.) Wenn Sie ein Commit in einer Zeile nicht angemessen kommentieren können, ist es bereits zu groß.

Um kleinere Commits zu üben, machen Sie sich in Ihrem Editor (oder im Editor) Notizen darüber, was Sie bereits geändert oder hinzugefügt haben. Übernehmen Sie, bevor eine lange Liste erstellt wird oder bevor Sie eine Codeänderung vornehmen, die nichts mit dem zu tun hat, was Sie bereits im Editor haben.

7
azheglov

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

  1. Führen Sie das Modell von vor 3 Monaten aus
  2. Wenn der Fehler immer noch ausgegeben wird, führen Sie das Modell 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 feinzahnigen Kamm hinsetzen, um die Ursache des Problems zu finden. Wenn das Festschreiben eine kleine Anzahl von Dateien berührt hat, ist es weniger schmerzhaft, die Codezeilen aufzuspüren, die das Problem verursacht haben.

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

6
Pete

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

Sie können beispielsweise jede Instanz von __macro1 In einer großen Codebasis in __macro2 Ändern, wodurch 200 Dateien geändert werden. 200 Verpflichtungen wären in diesem Fall nicht vernünftig.

Am Ende möchten Sie das Repository bei jeder einzelnen Revision abrufen und die Build-Arbeit ausführen. Haben Sie von libfoo zu libbar gewechselt? Ich hoffe, dass die Änderung auch die Aktualisierung Ihrer Build-Skripte und Makefiles (oder was auch immer zutreffend ist) umfasst.

Manchmal müssen Sie möglicherweise eine Reihe von experimentellen Änderungen vornehmen, die eines bewirken. In diesem Fall müssen Sie bestimmen, welcher Bereich für Sie wichtiger ist, wenn Sie später zurückkehren müssen. Hängt einer vom anderen ab? Legen Sie sie alle gleichzeitig in einer einzigen Revision fest. Andernfalls würde ich in diesem Fall ein Commit pro Änderung vorschlagen. Sie sollten so etwas in einer anderen Filiale oder in einem anderen Repo machen.

Ja, Sie haben zwar die Möglichkeit, eine einzelne Datei auf eine frühere Revision zurückzusetzen (wodurch eine Datei aus einer größeren Verpflichtung heraus gesichert wird), dies führt jedoch später zu Problemen wie der Halbierung und verschmutzt den Verlauf.

Wenn Sie innehalten und denken: "Ok, Tests bestehen, ich denke, das funktioniert. Aber wenn es schlecht wird, kann ich es dann einfach zurücksetzen?" .. Sie werden am Ende vernünftige Verpflichtungen eingehen.

5
Tim Post

Hier ist zu verstehen, dass es bei "Groß" in diesem Zusammenhang um die Anzahl der unterschiedlichen Änderungen geht, nicht um die physische Größe des Commits (obwohl im Allgemeinen die beiden Hand in Hand gehen).

Es ist nicht so eine Frage von "keine großen Commits machen" wie do kleine Commits machen - das ideale Wesen, um kleine, in sich geschlossene Änderungen zu machen.

Aus dem Changelog geht hervor, dass Sie eine Reihe von Dingen haben, die separat (und sicher) begangen werden könnten, und daher ist es ziemlich selbstverständlich, dass es zu groß ist.

Der Grund, warum dies ein Problem sein kann, ist, dass Ihr letztes 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 auf den Punkt zurückzusetzen, an dem Sie angefangen haben, Fehler zu machen (BTDTGTTS).

Natürlich sind Änderungen manchmal nur groß - umfangreiches Refactoring - und wie von anderen vorgeschlagen, müssen Sie hier verzweigen, obwohl Ihre individuellen Commits möglicherweise Dinge brechen, die vom Hauptentwicklungs-Trunk getrennt sind, so dass dies keine ist Problem und Sie können weiterhin früh und oft zu begehen.

Eine weitere Sache: Wenn während Ihrer Arbeit etwas passiert, das sofortige Aufmerksamkeit erfordert, müssen Sie es separat ändern (idealerweise in einem völlig unterschiedlichen Satz von Ordnern) und es 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 Zollkiesel auf dem Weg ist und dass an Losen nichts falsch ist von kleinen Commits und das Zusammenmischen verschiedener Dinge in einem Mob-Commit ist genauso schlimm wie das Munging vage verwandter Funktionen in einem Codeklumpen.

4
Murph

Trainieren Sie sich zumindest, wann immer Sie sich denken: "Ich mag meine bisherigen Fortschritte und 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 Sackgassen, die Sie versucht haben, oder speziellen Debugging-Code, den Sie hinzugefügt haben, um ein Problem aufzuspüren, zu beseitigen. (z. B. mit git reset --hard oder rm -rf *; svn update)

4
Ken Bloom

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

Es gibt ist jedoch eine Richtlinie, dass kleinere Commits im Rahmen der Vernunft besser sind (dh das Festschreiben jeder Zeile ist wahrscheinlich übermäßig).

Ich halte diese Art von Richtlinien im Auge:

  • 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 beschädigen

Natürlich - das ist es, woran ich denke - YMMV. Unterschiedliche Entwickler bevorzugen unterschiedliche Granularitätsstufen.

2
Bevan

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

Idealerweise sollte ein Commit atomar sein, im Sinne der kleinsten kohärenten Änderung der Codebasis (im Zusammenhang mit einem Fehler, einer Funktion usw.).

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

Der Schlüssel besteht darin, sich bei jeder atomaren Änderung auf Ihre "private" Niederlassung festzulegen. Anschließend können Sie Ihre Niederlassung regelmäßig zusammenführen, beispielsweise jede Woche.

Mit einem dvcs könnte Ihr Workflow folgendermaßen 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
1
Xavier T.

In meinem Fall versuche ich, Dateien eines Servers in das Repository-System (SVN) zu übertragen. Dies ist das anfängliche Commit und ich möchte es nicht herunterladen, da es sich um ein wirklich großes Projekt handelt (einige GB) und ich das anfängliche Commit vom Client-Server ausführen möchte.

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

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

Der Entwickler vor mir hat nie ein Versionskontrollsystem verwendet.

0
CGeorges

So beantworten Sie Ihre Fragen:

1) Für mich wird das Standard-Commit als groß angesehen, wenn es mehr als eine Sache tut. Mit Sache 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 zu verpflichten, wann immer Sie etwas beenden.

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

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

Ja, dies generiert eine große Anzahl von Commits, aber Sie können genau das zurücksetzen, was kaputt gegangen ist, anstatt eine große Reihe von Änderungen zurücksetzen 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. Wenn Sie eine davon verwenden, legen Sie fest, wann immer Sie eine Änderung vorgenommen haben, diese aber noch nicht getestet haben, und drücken sie dann an das zentrale Repository, wenn sie funktioniert. Dies ist vorzuziehen, da Sie so weitere Änderungen an Ihrem Code überarbeiten können, ohne sich Gedanken über das Unterbrechen des Builds machen zu müssen.

0
indyK1ng

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 das kleinste Inkrement, das Sie bequem versenden würden, wenn Sie den nächsten nicht rechtzeitig abschließen würden. Wenn Sie interne, häufig bereitgestellte Anwendungen erstellen, ist die beste Größe möglicherweise das kleinste Inkrement, das nichts kaputt macht (und Sie näher an den gewünschten Ort bringt).

Moderne Versionskontrollsysteme helfen Ihnen dabei, gute Commits mit einfacher Verzweigung, interaktiver Neugründung, Staging-Bereich usw. zu erstellen.

0

Commit-Nachrichten sollten nur eine Zeile lang sein (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 neige dazu, mich jedes Mal zu verpflichten (noch mehr, jetzt haben wir zu Git gewechselt). Ich habe einen Teil erledigt, da es ermöglicht, das "Warum" zu erfassen, das auf diese Weise getan wurde.

0
user1249

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

Mit git citool Können Sie auswählen, welche bestimmten Hunks einer Datei (oder welche bestimmten Zeilen) in einem bestimmten Commit festgeschrieben werden sollen, sodass 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 ausführt, aber Sie könnten git-svn, Den Subversion-Adapter für Git, verwenden, der Ihr Leben verändern wird.)

0
Ken Bloom

Je größer das Commit, desto wahrscheinlicher ist es, dass Sie den Build brechen und vom Rest Ihres Teams ausgezahlt werden. Ich versuche zweimal täglich Änderungen zu übernehmen. 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 sein, mich zu verpflichten. Ich finde, dass diese Praxis für mich funktioniert.

0
Nickz