it-swarm.dev

Was sind einige bewährte Methoden, bevor Sie den Quellcode einchecken?

Mein Team verwendet Team Foundation Server für die Quellcodeverwaltung. Heute habe ich einige Fehler behoben und die Anwendung zum Testen von Rauch getestet, bevor ich sie eingecheckt habe, aber ich habe vergessen, Code zu kommentieren. (Dieser Code hat die Benutzeroberfläche etwas seltsam gemacht.)

Ich möchte wissen, welche bewährten Methoden es gibt, bevor ich Code einchecke - ich möchte diesen Fehler nicht noch einmal machen.

47
Anonymous

Eine Sache, die ich mir angewöhnt habe, ist immer, die Unterschiede jeder Datei zu betrachten, die ich einchecken möchte, kurz bevor ich sie einchecke.

149
crudcore

Sie sollten niemals auskommentierten Code einchecken. Wenn Sie Code haben, der vor dem Einchecken auskommentiert werden muss, machen Sie es falsch.

Wie für Regeln:

  1. Bekomme das neuste
  2. Zusammenführungskonflikte beheben
  3. Bauen

    3.1 Buildfehler beheben

  4. Führen Sie Tests durch

    4.1 Fehlerhafte Tests beheben

  5. Gehe zu 1 (bis nichts mehr zu bekommen ist)

Checken Sie erst ein, wenn alle Schritte abgeschlossen sind.

Siehe Check-in-Tanz .


Andere bewährte Verfahren:

  • Überprüfen Sie die Liste der einzucheckenden Dateien, um sicherzustellen, dass es sich um die erwarteten Dateien handelt.
  • Überprüfen Sie die Änderungen für jede Datei (löscht/ergänzt/unterscheidet)
63
Oded

Ich versuche hier nicht, zu sehr ein Hosenwiesel zu sein, aber die Annahme in dieser Frage (und allen bis auf eine der Antworten) gilt hauptsächlich für zentralisierte VCS wie TFS, SVN, Perforce usw.
Fair genug, es ist das, was das OP verwendet.

Wenn Sie jedoch DVCS (wie Mercurial und Git) verwenden, sollten Sie normalerweise nicht mit dem Einchecken warten, und die meisten in den Antworten genannten Dinge - wie Unterschiede, Neueste, Zusammenführen usw. - sind nicht erforderlich . Sogar Dinge wie Codeüberprüfungen und Tests sind nach dem Einchecken besser (wenn auch vielleicht vor dem Push, abhängig von ...)
Die einzige Ausnahme, die ich hier (bisher) gesehen habe, ist die Zuordnung zu einem Arbeitselement. Natürlich ist es auch gut, das Einchecken zu kommentieren ...

20
AviD

Drei Dinge, die ich in anderen Antworten nicht gesehen habe:

Neue Dateien einschließen

  • Suchen Sie nach neuen Dateien, die nicht Teil Ihrer Änderungsliste sind
  • Möglicherweise spezifisch für SCMs wie Perforce - Sie müssen alles angeben, was in Ihrer Änderung enthalten ist.

Unveränderte Dateien zurücksetzen

  • Ich hasse es, wenn ich mir die Änderungen anderer Leute ansehe und es eine Änderungsliste mit neun Dateien gibt, von denen jedoch nur drei geändert wurden.
  • Ich mache auch Dateien mit Leerzeichen oder anderen bedeutungslosen Änderungen zurück.

Überprüfen Sie Ihr eingereichtes Commit

  • Stellen Sie sicher, dass der Build nach dem Festschreiben grün bleibt.
  • Früher hatte ich eine zweite Maschine, die ich nach meinen Commits synchronisierte, baute und ausführte. Wenn also etwas schief ging, konnte ich leicht hineinspringen und es reparieren.

Zwei Dinge, wenn ich Git benutze:

Atomic Commits:

  • Stellen Sie nur einzelne Funktionsänderungen für das Festschreiben bereit.
  • Machen Sie Commits so klein wie möglich. Machen Sie es einfach, sie zu patchen, zurückzusetzen und zu verstehen.
  • Ich benutze git add --patch, Um mein Wechselgeld bei Bedarf in mehrere Teile aufzuteilen.

Unterschiede beim Zusammenfassen anzeigen

  • Ich checke immer mit git commit --verbose Ein, damit ich einen Unterschied meiner Änderung sehen kann, während ich meine Commit-Nachricht eingebe. (Oder ich benutze mein gepatchtes git-vim , um den Unterschied zu zeigen.)
  • Dies macht es viel einfacher, Ihre Änderungen durchzugehen und das gesamte Commit zu beschreiben. Gelegentlich stelle ich zu diesem Zeitpunkt unbeabsichtigte Änderungen fest. (Wenn Sie Ihre Änderung beschreiben, können Sie darüber nachdenken.)
8
idbrii

Schimpfwörter suchen und ersetzen ;-)

7
Throwback1986

Einige bewährte Methoden, die ich auf den Servern meines Teams durchsetze, sind ziemlich einfach. Bevor Sie einchecken, sollten Sie immer auf dem neuesten Stand sein und einen lokalen Build ausführen, um sicherzustellen, dass niemand anderes überprüft hat, mit dem Ihr Code in Konflikt gerät. Achten Sie außerdem auf Codekonflikte auf Ihrem lokalen Computer und nicht auf dem Server. Sobald bestätigt wurde, dass Ihr Code mit dem neuesten heruntergeladenen Code ordnungsgemäß erstellt wurde und funktioniert, sind Sie für den nächsten Schritt bereit. Führen Sie alle automatisierten Tests durch und beginnen Sie mit dem Einchecken, um sicherzustellen, dass sie weiterhin ordnungsgemäß funktionieren. Dann, nur um sicherzugehen, werden Sie wieder auf dem neuesten Stand.

Als TFS-Administrator ist es möglich, das Kommentieren aller Check-Ins zu erzwingen. Ich würde empfehlen, immer Check-in-Kommentare für Ihre Arbeit einzugeben, unabhängig davon, ob diese erzwungen wird oder nicht. Wenn Sie die Möglichkeit dazu haben, erzwingen Sie dies. Stellen Sie sicher, dass die Kommentare mindestens eine allgemeine Zusammenfassung dessen sind, was Sie seit dem letzten Einchecken Ihres Codes geändert haben. Auf diese Weise können Sie, wenn etwas schief geht, die Check-Ins durchsehen und ungefähr sehen, was war in diesem Check-in geändert. Dies erleichtert das Debuggen eines fehlerhaften Builds erheblich.

Wenn Sie über TFS-Administratorrechte verfügen, erzwingen Sie außerdem fortlaufende Builds beim Einchecken (um sicherzustellen, dass alle anderen sofort wissen, ob beim Einchecken etwas kaputt geht), und Sie können den Server so einrichten, dass entweder ein gated Check-in durchgeführt wird ( Wenn der eingecheckte Code den Build bricht, lehnt der Server ihn ab. Sie können ihn auch einfach einen Fehler erstellen lassen und ihn demjenigen zuweisen, der den Build gebrochen hat.

Es gibt ein paar andere Optionen, die Sie ein- oder ausschalten können, um alles in Ordnung zu halten, oder die Sie Ihrem TFS-Administrator vorschlagen können, um sie einzuschalten, um die Dinge schön und sauber zu halten ... aber sie werden größtenteils bevorzugt

7
guildsbounty

Wenn Sie von Windows aus einchecken, überprüfen Sie, ob Ihr Code diese unsichtbaren ^ M-Zeichen nicht enthält. Die Editoren in UNIX geben häufig Fehler/Warnungen an.

Versuchen Sie auch, Tabulatoren zu ersetzen. Verschiedene Benutzer sehen Tabstops unterschiedlich, einige mit 4 Leerzeichen, andere mit 8 und nicht gut für die Lesbarkeit des Codes.

Meiner Meinung nach ist es am besten, wenn ein vordefiniertes Skript Ihren Code anhand der Codierungsrichtlinien Ihrer Organisation überprüft. Viele Versionsverwaltungssysteme verfügen über diese Funktionalität.

4
Fanatic23

In meiner Firma verwenden wir Check-in-Bewertungen. Diese müssen nicht detailliert sein, aber wenn Sie nur jemandem die Unterschiede in Ihrer Änderungsliste zeigen und sie durchgehen, wird manchmal der seltsame Tippfehler hervorgehoben, den Sie beim Testen verpasst haben.

Auf unserem Versionsverwaltungsserver können Sie nur dann einchecken, wenn Sie den Namen des Überprüfers in den Kommentaren vermerken (in der Form! Initialen, z. B.! BW, wenn Bruce Wayne Ihre Überprüfung durchgeführt hat). Der Prüfer erhält eine E-Mail mit der Mitteilung, dass er bei der Prüfung mitgewirkt hat. Dies ist offen für offensichtliche Ausbeutung, scheint aber ziemlich gut zu funktionieren.

4
tenpn

Wann immer möglich, verknüpfe ich einen Check-in gerne mit einem Arbeitselement. Dies gibt Ihnen einige kontextbezogene Informationen darüber, WARUM dies geändert wurde, nicht nur WAS wurde geändert. TFS verfügt über ein recht anständiges System zur Verfolgung von Arbeitselementen, sodass dies zum Zeitpunkt des Eincheckens eher trivial ist.

(Dies ist zusätzlich zur Überprüfung der Unterschiede meiner Änderungen)

4
mpeterson

Eine kleine Sache, die ich mache, ist, keine Dateien einzuchecken, die sich nicht wirklich geändert haben. Diese Dateien wurden möglicherweise versehentlich geändert oder waren an Refactorings beteiligt, die entweder zurückgesetzt oder auf andere Weise in Frage gestellt wurden.

Auf diese Weise enthält Ihr Änderungssatz (der einem Arbeitselement zugeordnet ist) genau die Dateien, die zur Erfüllung des Arbeitselements erforderlich sind.

3
John Saunders

Um alle Antworten hier zu kombinieren und eine vollständige Checkliste zu geben

  1. [Einchecken/Auschecken] Sie sollten nicht direkt in den Stream einchecken, in dem andere arbeiten. Sie sollten eine Stream-Strategie haben: z. Pro Entwickler einen Stream, in dem Sie unabhängig voneinander ein- und auschecken können, ohne andere zu stören: Ihre Arbeit ist sicher, aber in Ihrem eigenen Entwicklungsstrom, also [nur in Ihrem eigenen Entwicklungsstrom]. Bei jedem Einchecken verknüpfen Sie es mit einem Änderungsdatensatz, sodass Ihre Änderungen für diese Änderung, die als Änderungssatz bezeichnet wird, atomar sind (sodass Sie einzelne RFCs/Fehler usw. verteilen können, ohne "alles" liefern zu müssen).

  2. [dann mit Ihrem Team-Stream neu starten] bedeutet, dass Sie die Änderungen von anderen in Ihrem eigenen Stream erhalten. Während dieses Vorgangs können Sie im Zusammenführungsdialog alle "Unterschiede" sehen und durchgehen oder ... wenn es Tausende gibt und/oder Sie keinen Code verwenden, sondern auch z. Datenmodelle/Siebel-Projekte usw. basieren entweder auf nicht trivialen Zusammenführungen, trivial-automatischen und trivialen manuellen Zusammenführungen. Die letzte Kategorie enthält die schwierigen. Denken Sie daran, dass Sie immer noch in Ihrem eigenen Stream arbeiten.

  3. [vollständige Neueinstellung] Wenn alles in Ordnung ist, checken Sie alle Änderungen ein, die Sie gerade aus dem Team-Stream erhalten haben: Ihr eigener Stream ist jetzt auf dem neuesten Stand

  4. [liefern] Liefern Sie jetzt Ihre Arbeit an den Team-Stream. Wenn Sie nicht alles liefern möchten, können Sie auch z. 1 spezifischer RFC mit diesen spezifischen Versionen von Dateien oder einer Reihe von RFCs/Fehlern behoben.

  5. [test liefern] es sollte in Ordnung gehen, aber da die Möglichkeit besteht, dass sich in der Zwischenzeit auch jemand ändert: Sie können testen, ob Ihre Arbeit mit den neuesten Änderungen im Team-Stream funktioniert. Mit den gleichen Zusammenführungsdialogen werden Unterschiede angezeigt.

  6. [Lieferung abschließen] Vervollständige deine Lieferung und deine Arbeit ist jetzt im Team-Stream.

Um es komplexer zu machen: Da es immer noch die Möglichkeit gibt, dass die von Ihnen gelieferte Arbeit = ok ist, ABER Sie bereits an einer weiteren Version arbeiten, sollten Sie immer nach der Lieferung eine Baseline erstellen und angeben, von welcher Baseline diese für andere Benutzer bevorzugt wird . Dadurch wird sichergestellt, dass andere Entwickler eine empfohlene und nicht die neueste Version im Stream erhalten (wenn Sie in diesem Szenario arbeiten). Dies ist auch eine dreifache Überprüfung, sodass selbst wenn die neuesten Versionen im Team-Stream "schlecht" sind, sie immer noch nicht die sind, auf die andere zurückgreifen oder die sie sich ansehen, und Ihr Konfigurationsmanager kann dann die vorherige Version mit der nächsten Version zusammenführen, um sie rückgängig zu machen Ihre Lieferung.

  • die Antwort von Histumness kommt zweimal vor: in Schritt 2 und 6
  • die Antwort von Oded beim Check-in-Tanz: idem, aber eine zusätzliche Ebene für Zustellung und Rebase beim Check-in/Check-out, um sicherzustellen, dass Sie isoliert arbeiten und Fehler auch in späteren Phasen immer leicht behoben werden können
  • die Antwort von der beantworteten Gildenprämie: Holen Sie sich die neuesten Informationen ist Schritt 2. Für den Build: Es hängt wirklich davon ab, ob Sie einen Build haben ... in meiner Welt haben Sie Eingaben von Datenmodellen, Word-Dokumenten, Anforderungsblättern, Konfigurationsdaten von informatica, siebel, etc .. und ja auch Java Code, .net Code etc ... dass sich alle miteinander vermischen sollten. Es gibt hier also keinen wirklichen "Build", sondern eher eine höhere Integration, je nachdem ob Dieses einzelne, z. B. Build aus Ihrem "Code", lässt sich in den gesamten Rest des Materials integrieren, da Sie nicht sicher wissen können, ob es sich um Integrationsmaterial handelt. Abhängig von den Testumgebungen kann es sein, dass kompiliertes Material benötigt wird oder bei höheren Auslieferungen ein anderes Build, weil es braucht etwas von einem anderen Team.
  • die Antwort von Guildsbounty zum Kommentieren und Erfordernis: Ich denke, jede Umgebung, in der Sie keine Integration von VERSIONEN und Änderungen in Änderungssätzen haben (und Typ: Fehler, RFC, HotFI), ist nicht ausgereift. Ich denke, es ist ein Chaos, wenn Sie nicht z. Automatisieren Sie Versionshinweise mit der Anzahl der eingereichten Bugs und RFCs, die bis zu den genauen Versionen, die berührt werden, anklickbar sind (da z. B. Version 1 und Version 3 von hello.c sehr gut geliefert werden könnten, aber Version 2 wegen dieses Materials nicht hätte geliefert werden dürfen Es würde einen Teil einer späteren Version geben, aber einige Noobs haben ihn bereits eingefügt. (Dies bedeutet also eine manuelle Entscheidung, wenn Sie auch Version 3 von hello.c herausnehmen möchten. ABER das Herausnehmen von Version 3 bedeutet, dass Sie auch alle herausnehmen müssen andere Version, die von diesem RFC/Defekt betroffen ist, sodass Sie einfach und schnell mit einem Tool arbeiten können müssen, um das Ganze zu entfernen) (selbst wenn mehrere Entwickler an Teilen desselben RFC gearbeitet haben), aber zumindest benötigen Sie Dinge, um zu entscheiden drauf etc ...). Zusätzliche Dokumentation ist immer praktisch, aber durch das Verknüpfen von Änderungssätzen schließt sich der Kreis: eine Version <- ein Änderungssatz <- Arbeitselemente <- ein Ticket/RFC/Defekt <- eine Anforderung. Das heißt: Sie wissen, welche Anforderungen vollständig oder vollständig erfüllt sind: Eine Anforderung enthält mehrere RFCs oder Fehler oder was auch immer. Der RFC verfügt über mehrere Workitems für mehrere Personen. Dieses Arbeitselement entspricht einem Änderungssatz, der aus einem Satz von Versionen besteht (z. B. Version 1 und 3 von hello.c im Integrations-Stream, die natürlich NICHT die Versionen 1,2,3,4,5 in Ihrem Entwicklungs-Stream dieser Version sind 3 im Integrationsstrom entspricht) (daher ein Versionsbaum und Werkzeuge, um ihn zu bearbeiten)
  • der kommentar von luis.espinal: nicht brechen der build wird doppelt in rebase überprüft und liefert noch ... es gibt höhere lieferungen für 'release manager und build meisters', die Änderungssätze und Baselines als ihre Info sehen sollten. "Niemals direkt am Hauptzweig arbeiten" Ja, die Stream-Struktur kann groß oder einfach sein, aber im Wesentlichen: Entwickler haben ihren eigenen Stream, sie liefern an einen Team-Stream, der an einen Release-Stream liefert. -> damit die Lieferungen aller Teams (z. B. Dokumentationsteam, Anforderungsteam, Entwicklungsteams, Testteam) in ihren Team-Streams sind und ein Release-Manager oder Konfigurationsmanager die Baselines erfasst, die in einem Release enthalten sein sollen, und so sicherstellt, dass die Richtige Dokumentation mit den richtigen Testversionen Dokumente/Ergebnisse mit der richtigen Anforderung mit den richtigen Codeversionen stehen alle für eine Veröffentlichung bereit.

In Ihrem Beispiel geben Sie an, dass Sie vergessen haben, Code auskommentiert zu haben. Fehler passieren. Das Konfigurationsmanagementsystem sollte sich darum kümmern. Es kann wirklich sein, dass z.B. Tausende von Änderungen kommen herein und "Builds" und "Integrationen" finden in einer Hierarchie von Streams auf verschiedenen Servern statt, die zeitlich verkettet und verarbeitet werden. Selbst wenn Ihr auskommentierter Code nach 5 Monaten auf einem Integrationsserver getestet wird, weil Ihr Code in anderen Code und andere Systeme integriert werden muss, sollte es dennoch möglich sein, Ihren Änderungssatz atomar herauszunehmen und weiterzumachen. Die beste Vorgehensweise ist also mehr oder weniger auf einer höheren Ebene. Das Gesamtdesign der Konfigurationsverwaltungs-Streams sollte sich darum kümmern. Für einzelne Entwickler ist es natürlich die beste Vorgehensweise, einen Unit-Test zu validieren. Aber vom großen Ganzen bis zum "Funktionieren" ist es die beste Vorgehensweise, dem System zu folgen und den Jungs später in der Kette immer die Metainformationen der zugehörigen Änderungssätze zur Verfügung zu stellen.

3
edelwater

Einige der folgenden Punkte gelten je nach SCM mehr als andere (oder in verschiedenen Formen).

  1. Brechen Sie den Build nicht ab - überprüfen Sie nur den kompilierten Code.
  2. Kommentieren Sie Ihre Check-Ins (und möglicherweise Ihre Check-Outs, wenn Ihr SCM Ihnen diese Option bietet.)
  3. Lassen Sie Dinge nicht für längere Zeit unkontrolliert.
  4. Checken Sie häufig ein (wenn möglich mehrmals täglich).
  5. Sinnvoll beschriften.
  6. Regelmäßig beschriften.
  7. Arbeiten Sie niemals direkt am Hauptzweig.
  8. Jede Freigabe für die Produktion muss ein eigenes Label haben (und wenn möglich einen schreibgeschützten Zweig außerhalb des Hauptzweigs). Wenn möglich, machen Sie dasselbe für UAT/Integration/Pre-Production-Testversionen.
  9. Sie sollten in der Lage sein, genau das zu erstellen, was in der Produktion enthalten ist, und zwar aus dem, was sich in Ihrem SCM befindet, und aus einem Etikett.

NOTE : Einige der oben genannten Punkte scheinen ziemlich offensichtlich zu sein, aber Sie würden nicht glauben, wie viele Leute tatsächlich am Hauptzweig arbeiten oder zuerst Änderungen an der Produktion vornehmen - nd dann manuell Deltas erstellen, um die Versionskontrolle zu starten ... direkt im Hauptzweig ... und mit Beschriftungen. Süß wie fermentierte Galle gemischt mit ungewaschenem Achselsaftsaft ... ja, so.

2
luis.espinal

Haben Sie eine persönliche Checkliste. Starten Sie es leer, wenn Sie es vermasseln, an einem Eintrag. Wenn es zur zweiten Natur wird, entfernen Sie es aus der Liste.

Führen Sie die Tests aus. Wenn sie bestanden haben, checken Sie es ein. Wenn Sie durcheinander sind und etwas die Tests hinter sich lässt, schreiben Sie einen Test.

2
ctrl-alt-delor

Immer, immer, immer, überprüfen Sie, ob Änderungen, die Sie vorgenommen haben, den Build nicht beschädigen. Besonders kleine Änderungen, die trivial erscheinen mögen.

Einmal habe ich eine sehr kleine Änderung vorgenommen, von der ich nicht dachte, dass sie Probleme verursachen würde, kurz bevor ich für das Wochenende von der Arbeit ging. Sicher genug, diese kleine Änderung hat den Build gebrochen und es wurden keine nächtlichen Testläufe für unser Projekt durchgeführt. Der Q & A-Chef war darüber zu Recht nicht allzu glücklich.

1
gablin

Führen Sie Ihre Unit-Tests durch, an denen Sie so fleißig gearbeitet haben. Grün ist gut.

1
Naftuli Kay

Stellen Sie sicher, dass Ihr Code richtig formatiert ist (z. B. für Java: Wählen Sie Ihren Code aus und drücken Sie in Eclipse Strg-Umschalt-F). Seien Sie jedoch vorsichtig, wenn Sie dasselbe für ein gesamtes Dokument tun.

1
Rune Aamodt

Wir machen folgendes ...

  1. Test - Wir möchten sicherstellen, dass es funktioniert. Zumindest wollen wir wissen, dass es nichts kaputt macht.

  2. Codeüberprüfung oder zumindest eine Buddy-Überprüfung - Dies ist eine hervorragende Möglichkeit, um sicherzustellen, dass das Wissen verbreitet wird und die Mitarbeiter auf dem neuesten Stand gehalten werden. Es hilft auch, Fehler zu erkennen, bevor Dinge eingecheckt werden.

  3. Vorankündigung senden - Vor dem Einchecken wird eine Vorankündigung an die Gruppe gesendet. Der Zweck besteht nicht nur darin, anderen mitzuteilen, welche Dateien oder Bereiche sich ändern, sondern ihnen auch einen Hinweis zu geben (falls sie dies zur Kenntnis nehmen sollten), falls diese Änderungen sie voraussichtlich beeinflussen.

  4. Einige Stunden nach dem Absenden der Vorankündigung wird der Check-in durchgeführt und die Gruppe per E-Mail informiert. Jeder in der Gruppe kann wissen, wann die jeweilige Arbeit an einem Fehler oder einer Funktion abgeschlossen ist.

  5. Eine Kopie des Check-in-Hinweises wird in den Fixdatensatz eingefügt, der dem Fehler oder der Funktion zugeordnet ist. Beim Durchsuchen der Datensätze stellen wir fest, dass es sehr praktisch ist, eine Vorstellung davon zu haben, was die Korrektur/Funktion mit sich brachte.

1
Sparky

Suchen Sie nach Teilen Ihrer Änderungen, die als eigenständige Einheiten eingegeben werden können.

Oft gibt es einige Änderungen, wenn ich eine funktionierende Korrektur oder Verbesserung des Codes habe. Einige von ihnen sind spezifisch für die Verhaltensänderung, die ich anstrebe; andere sind Refactorings, die ich gemacht habe, um diese Änderung sauberer zu machen.

Ich ziehe es vor, jedes Refactoring einzeln mit einer eigenen Änderungsbeschreibung wie folgt einzuchecken:

REFACTORING: Benennen Sie X in Y um

X machte vorher Sinn, weil ... aber jetzt sollte es Y sein. Dies hängt mit der Arbeit für Ausgabe 9 zusammen.

Sobald jedes gute Refactoring eingecheckt ist, ist die endgültige Verhaltensänderung oft trivial.

Einige Änderungen wirken sich auch auf viele Codezeilen aus, sind jedoch nicht sehr interessant, während andere Änderungen sehr lokalisiert sind, aber wichtige Auswirkungen haben. Wenn diese Änderungen zusammen eingecheckt werden, kann es schwierig sein, die Unterschiede zu lesen. Also halte ich sie getrennt.

Später, wenn jemand die Änderungshistorie durchliest, ist es offensichtlich, wie die Dinge zum aktuellen Stand der Dinge gekommen sind und warum sie so sind. Es ist auch trivial, meine Verhaltensänderung rückgängig zu machen, da sie nicht mit Tonnen anderer Änderungen verwickelt ist.

1
Jay Bazuzi

Ich halte ein lokales HG-Repo für meine Arbeit.

  • Immer wenn ich etwas einchecke, schaue ich über den Diff und stelle sicher, dass alle Änderungen akzeptabel sind.
  • Ich versuche, die Hauptfunktion des Eincheckens zu beachten.
  • Ich versuche, jede Commit-Größe auf eine Schlüsselfunktion zu beschränken.

Ich behaupte nicht, dass dies die besten sind, aber sie funktionieren für mich.

0
Paul Nathan

Tun Sie, was Sie tun würden, wenn Sie etwas zurückgeben, das Sie von jemandem ausgeliehen haben. Stellen Sie sicher, dass es sauber und in gutem Zustand ist. Wenn Sie ein Durcheinander gemacht haben, müssen Sie es unbedingt reinigen, bevor Sie den Code an den Eigentümer (in den meisten Fällen an Ihren Arbeitgeber) zurücksenden.

0
Jason

Wenn ich Code schreibe, von dem ich weiß, dass er nicht eingecheckt werden soll, füge ich eine Zeile vor "// TEMP:" und danach mit "// END TEMP." Hinzu. Dies, zusammen mit Diff vor dem Einchecken, verspricht, dass ich diesen Code nicht versehentlich einchecken werde.

0
user17815

Testen Sie alles, was Sie hinzugefügt oder geändert haben, gründlich. Probieren Sie jeden erdenklichen Fall aus. Überlassen Sie das Testen nicht der Qualitätssicherung. Wenn ich für jedes Mal ein Sandwich hätte, wenn ich eine kleine Änderung vorgenommen hätte, und dann einige Testfälle ausprobiert hätte, um auf der sicheren Seite zu sein, und sofort Probleme gesehen hätte, hätte ich viele Sandwiches. Normalerweise sage ich mir laut: "Ich bin wirklich froh, dass ich das versucht habe ..."

Sie sagen, die Benutzeroberfläche sei nach Ihrer Änderung merkwürdig geworden. Wenn Sie nur das Programm ausgeführt und sich vor dem Einchecken die Benutzeroberfläche angesehen hätten, hätten Sie das Problem bemerkt?

0
Ken