it-swarm.com.de

Wann sollte ich mich zum ersten Mal zur Quellcodeverwaltung verpflichten?

Ich bin mir nie sicher, wann ein Projekt weit genug ist, um sich zuerst der Quellcodeverwaltung zu widmen. Ich neige dazu, das Festschreiben zu verschieben, bis das Projekt "Framework-abgeschlossen" ist, und von da an lege ich hauptsächlich Funktionen fest. (Ich habe keine persönlichen Projekte durchgeführt, die groß genug sind, um ein zu großes Kern-Framework dafür zu haben.) Ich habe das Gefühl, dass dies keine bewährte Methode ist, obwohl ich nicht sicher bin, was schief gehen könnte.

Angenommen, ich habe ein Projekt, das aus einer einzelnen Codedatei besteht. Es werden ungefähr 10 Zeilen Boilerplate-Code und 100 Zeilen benötigt, um das Projekt mit äußerst grundlegenden Funktionen (1 oder 2 Funktionen) zum Laufen zu bringen. Soll ich zuerst einchecken:

  1. Die leere Datei?
  2. Der Boilerplate-Code?
  3. Die ersten Features?
  4. An einem anderen Punkt?

Was sind auch die Gründe, an einem bestimmten Punkt einzuchecken?

121
Kendall Frey

Sie sollten sich verpflichten, sobald Sie eine vernünftige "Einheit" abgeschlossen haben.

Was ist eine Einheit? Es hängt davon ab, was Sie tun. Wenn Sie beispielsweise ein Visual Studio-Projekt erstellen, schreiben Sie die Lösung direkt nach ihrer Erstellung fest, auch wenn sie nichts enthält.

Von da an sollten Sie so oft wie möglich festschreiben, aber immer noch nur abgeschlossene "Einheiten" festschreiben (z. B. Klassen, Konfigurationen usw.). Dies erleichtert Ihnen das Leben, wenn etwas schief geht (Sie können eine kleine Anzahl von Änderungen rückgängig machen) und verringert die Wahrscheinlichkeit von Konflikten.

104
Albireo

Meiner Meinung nach ist Ihr Versionsverwaltungs-Repo Teil des grundlegenden Projekt-Setups. Daher verpflichte ich mich direkt nach dem Generieren meines leeren Projekts.

143
John MacIntyre

Gestern

... alternativ, wenn Sie nicht in der Lage sind, Zeitreisen zu unternehmen ...
(Vielleicht kann Ihr Auto nicht auf 88 Meilen pro Stunde kommen oder Ihr Flusskondensator ist gerade gerissen)

Jetzt

Neue Projekte sollten an der blutigen Stelle begangen werden, es ist verrückt, dies nicht zu tun, und moderne DVCS-Systeme haben gerade jede mögliche Ausrede entfernt, um Festschreibungen zu vermeiden: git init . ; git add * ; git commit -m initial-commit jetzt, bevor es zu spät ist, wie es vielleicht schon ist.

Eine weitere vernünftige, fragwürdige Frage könnte gewesen sein: "Wann sollte ich zusammenführen meine Commits zu einem gemeinsam genutzten Quellcodeverwaltungssystem in einem vom Team verwalteten Repository auf ein etabliertes Projekt? " (Beachten Sie die Adjektive, Adjektive sind wichtig) Und ich habe das Gefühl, dass die meisten anderen Antworten tatsächlich versuchen, darauf zu antworten.

Ihr persönlicher Zweig sollte verpflichtet sein, vor dem Schlafengehen mindestens einmal am Tag wie verrückt. Sie könnten am nächsten Morgen aufwachen und feststellen, dass Sie keine Ahnung haben, was zum Teufel Sie in der vergangenen Nacht vorhatten. Das VCS sollte Sie dagegen schützen, und die Möglichkeit, auf eine sehr aktuelle Unterversion einer Unterversion zurückzusetzen, die gut kompiliert wird, reibungslos funktioniert und/oder Tests besteht, ist möglicherweise die beste Option.

77
ZJR

Ich würde so schnell wie möglich Commit sagen. Der Hauptzweck der Quellcodeverwaltung besteht darin, dass Sie für den Fall, dass etwas schief geht, zurückkehren können. Dies steht im Einklang mit der Übung "Früh und häufig festschreiben".

Persönlich enthält mein erstes Commit normalerweise nur die Datei . Gitignore (oder eine entsprechende Datei) mit wenigen Filtern, von denen ich weiß, dass sie benötigt werden, wie *. Py [co] für Python Code. Grundlegendes Projekt-Setup und/oder erster einfachster Prototyp folgt normalerweise.

20
Xion

Das erste Commit kann eine README -Datei mit nur einer einzeiligen Zusammenfassung des Projekts oder genügend Informationen zum ersten Meilenstein des Projekts sein. Die allgemeinen Themen können auch Folgendes umfassen:

  • Einführung
  • Projektbeschreibung
  • Projektstruktur
  • Codierungskonventionen
  • Anleitung zum:
    • bauen
    • prüfung
    • bereitstellen
  • Bekannte Probleme und Problemumgehungen
  • aufgabenliste
  • Nutzungsbedingungen

Das Aktualisieren von README vor dem Vornehmen von Änderungen an einem Projekt wird auch als Readme Driven Development bezeichnet und ermöglicht es Ihnen, die Änderungen zu überdenken, bevor Sie Zeit in das Vornehmen investieren diese Änderungen.

Jeder, der zu dieser Software beitragen oder sie nutzen möchte, beginnt mit der README-Datei.

16
user73449

Wenn Sie Arbeiten ausgeführt haben, die Sie nicht verlieren möchten, sollten Sie diese in Ihrem Versionsverwaltungssystem haben.

Dies gilt sicherlich für verteilte Systeme wie Git. Wenn Sie ein zentrales System verwenden und die einzige Möglichkeit, etwas einzuchecken, darin besteht, es für alle sichtbar zu machen, möchten Sie möglicherweise zurückhalten - oder Sie möchten Erwägen Sie, ein eigenes lokales Git-Repository einzurichten und es an das zentrale System zu senden, wenn Sie bereit sind.

12
Keith Thompson

Meine Faustregel lautet, dass ich einchecke, sobald meine Lösungsdatei (oder ein anderes Build-Skript) fertig ist, auch wenn sie einige leere Dateien enthält. Es ist eine gute Praxis, wenn mehr als eine Person an dem Projekt arbeitet. Diese Datei weist anfangs in der Regel die schlimmsten Probleme beim Zusammenführen auf, da die Benutzer dem Projekt Dinge hinzufügen, sodass sie frühzeitig und häufig festgelegt werden müssen.

Selbst wenn Sie der einzige sind, der an dem Projekt arbeitet und nur eine Datei enthält, fällt es mir leichter, dem gleichen Workflow zu folgen und die Überlegungen für das jeweilige Problem zu speichern.

7
Telastyn

Nicht sicher , ob es erwähnt wurde.

Aber stellen Sie sicher dass das, was Sie festschreiben, ausgeführt/kompiliert wird! Also keine Syntaxfehler etc.

Nichts ist frustrierender als das Auschecken von Code, der kaputt ist.

6
Roger

Kurz bevor du etwas Dummes tust.

Für diejenigen von uns ohne magische Kräfte bedeutet das wenig und oft.

Wenn Sie alleine arbeiten, tun Sie es jedes Mal, wenn Sie etwas trinken oder was auch immer.

Wenn Sie in einem Team arbeiten, müssen Sie wahrscheinlich sicherstellen, dass das Ding kompiliert wird, damit jemand anderes, der auf dem neuesten Stand ist, keine Fehler bekommt. Aber anders als das, so viel du kannst.

5
Tom Morgan

Eine andere Sichtweise, die eher mit Softwaretests (TDD-Ansatz) zusammenhängt, ist das Festschreiben, sobald Sie neue Testfälle in Grün haben. Dies würde bedeuten, dass Sie eine neue "Codeeinheit" fertiggestellt haben.

5
frandevel

Etwa 2 bis 3 Stunden nach Projektbeginn.

Nur ein Scherz. Es gibt keine gute Antwort, die in alle Situationen passt. Wenn Sie über ein verteiltes Versionskontrollsystem (wie git oder Mercurial) verfügen, werden Ihre Daten im Falle eines katastrophalen Ausfalls nicht durch das Festschreiben an Ihr lokales Repo erhalten. Ein privates Remote-Repo kann Sie jedoch Geld kosten, z. auf Github. Sie werden den Commit-Verlauf beibehalten, aber meiner Erfahrung nach werden Sie diesen erst benötigen, wenn Ihr Projekt etwas fortgeschritten ist.

Außerdem möchten Sie am Anfang wahrscheinlich nicht zu viel Abwanderung, insbesondere wenn Sie Dateien verschieben. Änderungen zu begehen wird eine Belastung sein, wenn auch nur eine kleine. Sie können sogar beschließen, das Ding wegzuwerfen. Wenn Sie jedoch Änderungen verlieren, deren Replikation nicht trivial ist, werden Sie keine Sicherungskopie erstellt, und Versionskontrollsysteme sind äußerst wertvolle Sicherungssysteme.

Einige Leute benutzen heutzutage DropBox oder ähnliches, um ihren Code zu speichern. Dies kann zu Beginn eines Projekts ein guter Kompromiss sein, da die Einrichtung keinen Aufwand erfordert. Es ist jedoch eine barbarische Angewohnheit bei ernsthafter Softwareentwicklung, insbesondere wenn mehrere Personen gleichzeitig den Code berühren.

Daher neige ich dazu, die Versionskontrolle einzurichten, wenn ich etwas Wertvolles habe, d. H. Nicht trivial zu replizieren. Der Wert ist subjektiv (und hängt von den eigenen Fähigkeiten ab), daher müssen Sie Ihr eigenes Urteil fällen. Zu diesem Zeitpunkt speichere ich ein zweites Repo auf einer externen Festplatte oder auf Github, wenn es sich um ein öffentliches Projekt handelt oder mein Zahlungskonto es hält.

4
alexfernandez

Viele Leute haben bereits "Sofort" geantwortet, und ich stimme zu 100% zu. Ich mag auch Xions Vorschlag , um mit den Ignoriermustern des VCS zu beginnen (d. H. .gitignore oder gleichwertig).

Ich denke, man ist sich ziemlich einig, dass frühe Commits keine Nachteile haben. Ich möchte Upsides hinzufügen:

  • Es ist weniger wahrscheinlich, dass Sie Dinge begehen, die Sie wegwerfen möchten, aber das bleibt immer noch bestehen. Wenn ich eine neue Entwicklung starte, werde ich schnell Code codieren und entfernen. Wenn ich später festschreibe, wenn bereits eine Reihe von Dateien vorhanden sind, habe ich versehentlich Inhalte festgeschrieben, um sie beim nächsten Festschreiben zu löschen. Dies ist im Gegensatz zu kleinen oder sogar leeren Commits wahres Rauschen in der Geschichte.
  • Wenn Sie ein systematischer Typ sind und typische erste Schritte in Ihren Projekten haben, kann es für Sie oder andere hilfreich sein, diese als Festschreibungspunkte zu haben, und es kann sogar die Möglichkeit bieten, an einem bestimmten Punkt abzweigen und einen wiederverwendbaren Projektstub zu erstellen. Ich habe an Maven-basierten Projekten gearbeitet, bei denen dies nützlich war (da beim Einrichten eines Maven-Projekts einige kleine erste Schritte bereits eine beträchtliche Basis definieren können, und obwohl diese Schritte nicht viel zu sind. tun , erfordern sie möglicherweise genug Denken , um die Wiederverwendbarkeit zu gewährleisten).
3
Hanno Fietz

Wenn ich ein neues Projekt starte, beginne ich normalerweise damit, dies festzuschreiben, bevor Code hinzugefügt wurde. Eine allgemeine Faustregel, die ich immer befolgt habe, lautet: Wenn Ihr PC abstürzt und alle Ihre Daten löscht, welchen Code möchten Sie lieber nicht aus dem Speicher schreiben? Vor zehn Jahren vor TDD und besserer Programmierpraxis war ich ziemlich optimistisch, woran ich mich erinnern konnte. Jetzt bin ich eher vorsichtig. Wie viele andere Plakate bereits gesagt haben, verpflichten Sie sich frühzeitig und häufig. Sie verlieren nichts, wenn Sie es tun.

Ich arbeite die meiste Zeit alleine, also muss ich gestehen, dass ich schlaff werde, aber ich verpflichte mich im Allgemeinen, bevor ich nach Hause gehe. Auf diese Weise können meine Kollegen dort weitermachen, wo ich aufgehört habe, wenn ich es morgen nicht schaffe.

Ich benutze derzeit Tortoise/SVN bei der Arbeit.

2

Commit das leere Projekt sofort. Legen Sie mehrmals pro Stunde fest, wie Sie an dem Projekt arbeiten. Festschreiben, auch wenn der Code nicht kompiliert wird. Ich markiere solche Commits mit "WIP" in der Commit-Massage, um sie im Auge zu behalten.

Ich habe auch ein Skript, das alle meine Projekte automatisch alle 10 Minuten in ein Backup-Repo festschreibt, für den Fall, dass ich vergesse, es manuell festzuschreiben. Nennen wir es meinen Cloud-gestützten Rückgängig-Puffer.

Einchecken (aka. Drücken Sie ) das Projekt zu einem Team-Repo, wenn Ihr Team Ihren Code sehen soll. Das ist wahrscheinlich, bevor Ihr Code für Ihr Team sichtbar ist, wenn Sie so etwas wie ich sind.

Wenn Sie nett zu Ihrem Team sein möchten, Squash Ihre Commits, bevor Sie sie zum Team-Repo schieben.

2
Minthos

Es kann davon abhängen, welches VCS Sie verwenden.

Mit Git lege ich ein leeres Verzeichnis fest (oder mit einer fast leeren README -Datei). Der Punkt ist, dass ich zurückgehen und meinen Zweig in diesen leeren Zustand zurücksetzen kann, wenn ich vollständig von vorne beginnen möchte Während ich mich noch in einem frühen Stadium des Entwicklungsprozesses befinde (bevor ich den Upstream vorantreibe), würde ich dann meine "generierten" Dateien festschreiben (z. B. Visual Studio-Lösung). Wenn ich dann tatsächlich codiere, beginne ich, jede Einheit wie gewohnt festzuschreiben.

Mit SVN pushen Sie mit jedem Commit den Upstream, sodass Sie nicht den Luxus haben, wie bei Git von vorne zu beginnen. In diesem Fall ist es möglicherweise nicht vorteilhaft, frühzeitig eine Verpflichtung einzugehen, wenn Sie der Meinung sind, dass Sie zu Beginn des Prozesses größere Änderungen vornehmen werden. Das liegt jedoch an der Person, die codiert.

2
Joe Phillips

Ich habe alle Artikel durchgesehen und ich denke, wir haben bereits viele gute Lösungen, aber ich möchte meine Methodik mit Ihnen teilen.

Während der Arbeit an der Framework-Erstellung (von Grund auf neu) werden für jedes Modul viele Änderungen vorgenommen, bis das Modul abgeschlossen oder abgeschlossen ist. Ich habe also immer 2 Standorte, einer heißt DYNAMISCH und der andere ist STATISCH. Wenn Änderungen vorgenommen werden und das Framework noch nicht fertiggestellt ist, wurde es am DYANMIC-Speicherort festgeschrieben. Sobald es abgeschlossen und abgeschlossen ist, verschiebe ich es an den STATIC-Speicherort. Ich habe also eine vollständige Quellcodeverwaltung.

Vielen Dank

1
Logicalj

Normalerweise checke ich ein, wenn ich etwas Neues hinzufüge, versuche aber, Dinge in diskreten Commits zu trennen.

Das heißt, wenn ich eine neue Abhängigkeit hinzufüge, nehme ich die Änderungen vor, bis sie entweder kompiliert werden oder groß genug sind, dass es Zeit verlieren würde, sie erneut von Grund auf neu auszuführen. Wenn ich eine größere Aufgabe habe, versuche ich, sie mehrmals festzuschreiben, wenn dies sinnvoll ist (einmal pro Funktion, jedes Mal, wenn ich sie kompilieren und erfolgreich ausführen lasse usw.).

Ich verpflichte mich auch, wenn ich einen Sicherungspunkt möchte (dh "wenn das, was ich jetzt versuche, nicht funktioniert oder zu kompliziert wird, möchte ich zum aktuellen Code zurückkehren" oder wenn mich jemand bittet, das zu löschen, was ich bin ein dringendes Problem beheben.

Wenn Sie ein zentrales Versionsverwaltungssystem verwenden, können Sie keine willkürlichen Festschreibungen für Sicherungspunkte vornehmen, da eine Festschreibung, die nicht kompiliert/funktioniert, alle in Ihrem Team betrifft.

Wenn ich mit dem Hinzufügen von Boilerplate-Code beginne (z. B. Hinzufügen einer neuen Webanwendung in einer Django Website)), lege ich normalerweise jede Operation fest, die ich mache.

Wenn ich einem Lernprogramm zum Generieren/Schreiben von Code folge, verwende ich im Lernprogramm Schrittnamen für Festschreibungsnachrichten. Auf diese Weise kann ich Revisionen unterscheiden und zu einem späteren Zeitpunkt sehen, was ein Tutorial-Schritt bewirkt hat.

Angenommen, ich habe ein Projekt, das aus einer einzelnen Codedatei besteht. Es werden ungefähr 10 Zeilen Boilerplate-Code und 100 Zeilen benötigt, um das Projekt mit äußerst grundlegenden Funktionen (1 oder 2 Funktionen) zum Laufen zu bringen.

Es würde davon abhängen, wie schwierig das Hinzufügen des Materials ist:

  • wenn es trivial wäre, den Kesselplattencode hinzuzufügen, würde ich ihn hinzufügen und festschreiben, bevor ich mit dem anderen Code beginne (auf diese Weise kann ich, wenn ich einen Fehler mache oder später einen seltsamen Fehler einführe, einfach zum Kesselplattencode zurückkehren und starten nochmal).

  • Wenn der Code nicht trivial wäre, würde ich jedes Mal ein Commit durchführen, wenn ich etwas Neues hinzufüge (irgendwo zwischen jeweils zwei geänderten Codezeilen, ungefähr hundert).

0
utnapistim

Mit jeder Anwendung werden Sie einige Zeit damit verbringen, die Komponenten zu entwerfen. Sie sollten Ihre Namensräume, Projekte, externen Referenzen, Bibliotheken von Drittanbietern usw. grob oder ausführlich kennen.

Wenn Sie in einem Team sind, würde ich vorschlagen, dass Ihr Lead oder wer auch immer ausgewählt wird, um das Basisprojekt zu erstellen, die Abhängigkeiten festzulegen und das Skelett (Fundament, auf dem Ihr Projekt aufgebaut wird) zu überprüfen.

Sie möchten auch sicherstellen, dass Ihre Aufgaben-, Release-, Trunk- usw. Zweige vor dem Einchecken festgelegt wurden, damit Ihr Prozess solide ist.

Wenn Sie an einer neuen "Aufgabe" für ein bereits laufendes Projekt arbeiten und sich in Ihrem eigenen Aufgabenbereich befinden, führen Sie Ihre nächtlichen Check-ins durch, damit Sie Ihre Arbeit erhalten.

0
Ryan Ternier