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 vollständig 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 Vorgehensweise 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 Kesselschildcode?
3. Die ersten Funktionen?
4. An einem anderen Punkt?

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

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 Projektmappe direkt nach ihrer Erstellung fest, auch wenn sie nichts enthält.

Von da an sollten Sie so oft wie möglich Commits durchführen, aber dennoch nur abgeschlossene "Units" (z. B. Klassen, Konfigurationen usw.) durchführen. Dies erleichtert Ihnen das Leben, wenn etwas schief geht (Sie können einige Änderungen rückgängig machen) und verringert die Wahrscheinlichkeit von Konflikten.

Soweit es mich betrifft, ist Ihr Quellcodeverwaltungs-Repo Teil des grundlegenden Projekt-Setups, sodass ich das Commit sofort nach dem Generieren meines leeren Projekts vornehme.

Gestern

... als Alternative, wenn Sie nicht in der Lage sind, eine Zeitreise
zu unternehmen ...

Jetzt

Neue Projekte sollten auf der verdammten Stelle umgesetzt werden, es ist verrückt, das nicht zu tun , und moderne DVCS-Systeme haben gerade jede mögliche Entschuldigung beseitigt, um ein Commit zu vermeiden : git init . ; git add * ; git commit -m initial-commitJetzt, bevor es zu spät ist, wie es vielleicht schon ist.

Eine sinnvolle, diskutierbar, Frage gewesen sein könnte: „Wann soll ich fusioniere meine Commits zu einer gemeinsamen Source - Control auf einem Team verwaltet Repository auf einem 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 , mindestens einmal am Tag vor dem Schlafengehen verrückt zu sein . Vielleicht wachst du erst am nächsten Morgen auf und stellst fest, dass du in der vergangenen Nacht keine Ahnung hast, was zum Teufel du vorgehabt hast. Das VCS sollte Sie davor schützen und die Möglichkeit haben, ein Rollback auf eine sehr aktuelle Unterversion einer Unterversion durchzuführen, die sich gut kompilieren lässt, reibungslos funktioniert und / oder Tests besteht.

Ich würde sagen, verpflichten Sie sich so bald wie möglich. Der Hauptzweck der Quellcodeverwaltung besteht darin, dass Sie zurückgehen können, falls etwas schief geht, und dies spiegelt sich in der Übung "Früh und oft festschreiben" wider.

Persönlich enthält mein erstes Commit normalerweise nur die .gitignore- Datei (oder eine entsprechende Datei) mit wenigen Filtern, von denen ich weiß, dass sie benötigt werden, wie * .py [co] für Python-Code. Es folgt in der Regel die grundlegende Projekteinrichtung und / oder der erste einfachste Prototyp.

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

• Einführung
• Projektbeschreibung
• Projektstruktur
• Kodierungskonventionen
• Anleitung zum:
  • bauen
  • Prüfung
  • bereitstellen
• Bekannte Probleme und Problemumgehungen
• Aufgabenliste
• Nutzungsbedingungen

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

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

Wenn Sie Arbeiten erledigt 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 sich möglicherweise zurückhalten - oder Sie überlegen, ein eigenes lokales Git-Repository einzurichten und es an das zentralisierte einzureichen System, wenn Sie bereit sind.

Als Faustregel gilt, dass ich meine Lösungsdatei (oder ein anderes Build-Skriptstück) einchecken muss, 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 bei der Zusammenführung auf, da die Leute dem Projekt Dinge hinzufügen, die früh und häufig festgeschrieben werden müssen.

Selbst wenn Sie der einzige sind, der an dem Projekt arbeitet und nur eine Datei hat, finde ich es einfacher, dem gleichen Workflow zu folgen und die Überlegungen für das jeweilige Problem zu speichern.

Ich bin mir 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 kaputten Code auszuchecken.

Eine andere Sichtweise, die eher mit Softwaretests zu tun hat (TDD-Ansatz), würde sich ergeben, sobald Sie neue Testfälle in Grün haben. Dies würde bedeuten, dass Sie eine neue "Codeeinheit" abgeschlossen haben.

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 niemandem eine Tüte mit Fehlern angezeigt wird, wenn jemand anderes auf dem neuesten Stand ist. Aber anders als das, so viel du kannst.

Etwa 2 ~ 3 Stunden in das Projekt.

Ich mache nur Spaß. Es gibt keine gute Antwort, die in alle Situationen passt. Erstens, wenn Sie über ein verteiltes Versionskontrollsystem (wie Git oder Mercurial) verfügen, werden Ihre Daten im Falle eines katastrophalen Ausfalls nicht erhalten, wenn Sie sich für Ihr lokales Repo verpflichten. Aber ein privates Remote-Repo kann Geld kosten, zB bei Github. Sie werden die Festschreibungshistorie beibehalten, aber meiner Erfahrung nach werden Sie diese 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 entscheiden, das Ding wegzuwerfen. Wenn Sie jedoch Änderungen verlieren, die nicht einfach zu replizieren sind, wird Ihnen die Erstellung einer Sicherungskopie fehlen, 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 keinerlei Aufwand erfordert. Es ist jedoch eine barbarische Angewohnheit bei der ernsthaften Softwareentwicklung, insbesondere wenn mehrere Personen gleichzeitig den Code berühren.

Daher neige ich dazu, die Versionskontrolle immer dann einzurichten, wenn ich etwas Wertvolles habe, das sich nicht trivial replizieren lässt. Der Wert ist subjektiv (und hängt von den eigenen Fähigkeiten ab), sodass Sie Ihr eigenes Urteil fällen müssen. 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 zahlendes Konto es enthält.

Viele Leute haben bereits "Sofort" geantwortet und ich stimme zu 100% zu. Ich mag auch den Vorschlag von Xion , mit den Ignoriermustern (dh .gitignoreoder gleichwertigen) des VCS zu beginnen .

Ich denke, man ist sich ziemlich einig, dass frühe Commits keine Nachteile haben. Ich würde gerne die Vorteile hinzufügen:

• Es ist weniger wahrscheinlich, dass Sie Dinge begehen, die Sie verwerfen möchten, aber das bleibt immer noch so. Wenn ich eine neue Entwicklung beginne, codiere und diskriminiere ich schnell. Wenn ich später ein Commit durchführe, und wenn bereits eine Reihe von Dateien vorhanden sind, habe ich versehentlich ein Commit ausgeführt, um es beim nächsten Commit zu löschen. Im Gegensatz zu kleinen oder sogar leeren Commits ist dies 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 eine Anleitung sein, diese als Festschreibungspunkte zu verwenden, und es kann sogar die Möglichkeit bieten, an einem bestimmten Punkt abzweigen und einen wiederverwendbaren Projektstumpf 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 Grundlage bilden können. Diese Schritte sind zwar nicht viel zu tun , erfordern jedoch möglicherweise genügend Überlegungen, um dies zu rechtfertigen Wiederverwendbarkeit).

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 den leeren Zustand zurücksetzen kann, wenn ich noch zu Beginn des Entwicklungsprozesses (bevor ich ihn in den Upstream schiebe) komplett von vorne anfangen möchte. Ich würde dann meine "generierten" Dateien festschreiben (zB Visual Studio-Lösung). Wenn ich dann tatsächlich codiere, lege ich jedes Gerät wie gewohnt fest.

Mit SVN werden Sie bei jedem Commit einen Push-Upstream ausführen, sodass Sie nicht den Luxus haben, von vorne zu beginnen, wie Sie es mit Git tun. In diesem Fall ist ein frühzeitiges Festschreiben möglicherweise nicht von Vorteil, wenn Sie der Meinung sind, dass Sie frühzeitig eine umfassende Umgestaltung durchführen werden. Das hängt jedoch von der Person ab, die den Code erstellt.

Wenn ich ein neues Projekt starte, beginne ich normalerweise damit, dass ich das festschreibe, bevor Code hinzugefügt wurde. Eine allgemeine Faustregel, die ich immer befolgt habe, lautet: Wenn Ihr PC abgestürzt ist und alle Ihre Daten gelöscht hat, welchen Code möchten Sie nicht aus dem Speicher schreiben müssen? Vor zehn Jahren vor TDD und einer besseren Programmierpraxis war ich ziemlich optimistisch in Bezug auf das, woran ich mich erinnern konnte. Jetzt neige ich dazu, vorsichtiger zu sein. Wie viele andere Plakate bereits gesagt haben, begehen Sie frühzeitig und begehen Sie häufig. Sie verlieren nichts, indem 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.

Übernehmen Sie das leere Projekt sofort. Verpflichten Sie sich mehrmals pro Stunde, die Sie mit der Arbeit an dem Projekt verbringen. Festschreiben, auch wenn der Code nicht kompiliert wird. Ich markiere solche Commits mit "WIP" in der Commit-Massage, um sie zu protokollieren.

Ich habe auch ein Skript, das alle meine Projekte automatisch alle 10 Minuten in ein Backup-Repo schreibt, für den Fall, dass ich das manuelle Commit vergesse. Nennen wir es meinen Cloud-Backed Undo Buffer.

Check - in (aka. Drücken ) , um das Projekt zu einer Team - Repo , wenn Sie Ihr Team benötigen Sie den Code zu sehen. Was wahrscheinlich ist, bevor Ihr Code von Ihrem Team gesehen werden kann, wenn Sie so etwas wie ich sind.

Wenn du nett zu deinem Team sein willst, drücke deine Commits, bevor du sie in das Team-Repo schiebst.

Ich habe alle Artikel durchgesehen und 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 viele Änderungen für jedes Modul vorgenommen, bis das Modul abgeschlossen oder abgeschlossen ist. Ich habe also immer 2 Standorte, von denen einer als DYNAMISCH und der andere als STATISCH bezeichnet wird. Wenn Änderungen vorgenommen werden und das Framework noch nicht abgeschlossen ist, wurde es an der DYANMIC-Position festgeschrieben. Sobald es abgeschlossen und abgeschlossen ist, verschiebe ich es an die STATIC-Position. Ich habe also eine vollständige Quellcodeverwaltung.

Vielen Dank

Bei jeder Anwendung verbringen Sie einige Zeit mit dem Entwerfen der Komponenten. Sie sollten Ihre Namensräume, Projekte, externen Referenzen, Bibliotheken von Drittanbietern usw. grob oder ausführlich kennen.

Wenn Sie Mitglied eines Teams sind, würde ich vorschlagen, dass Sie oder eine der ausgewählten Personen das Basisprojekt erstellen, die Abhängigkeiten festlegen und das Skelett (Fundament, auf dem Ihr Projekt aufbauen wird) überprüfen.

Sie möchten auch sicherstellen, dass Ihre Aufgabe, Ihr Release, Ihr Trunk usw. Zweige festgelegt sind, bevor Sie einchecken, 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, checken Sie jeden Abend ein, damit Ihre Arbeit erhalten bleibt.

Normalerweise checke ich immer 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 so lange vor, bis sie entweder kompiliert werden oder groß genug sind, um sie von Grund auf neu zu erstellen. Wenn ich eine größere Aufgabe habe, versuche ich, sie mehrmals festzuschreiben, wenn es Sinn macht (einmal pro Funktion, jedes Mal, wenn ich sie erfolgreich kompilieren und ausführen lasse usw.).

Ich gebe auch fest, wenn ich einen Backup-Punkt haben möchte (z. B. "Wenn das, was ich jetzt versuche, nicht funktioniert oder zu kompliziert wird, möchte ich zum Code zurückkehren, wie er jetzt ist", oder wenn jemand mich auffordert, das, was ich bin, fallen zu lassen dringende Probleme beheben).

Wenn Sie ein zentrales Quellcodeverwaltungssystem 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. eine neue Webanwendung in einer Django-Website), setze ich normalerweise jede meiner Aktionen fest.

Wenn ich einem Lernprogramm zum Generieren / Schreiben von Code folge, verwende ich im Lernprogramm Schrittnamen für Commit-Nachrichten. Auf diese Weise kann ich Revisionen unterscheiden und sehen, was ein Lernschritt zu einem späteren Zeitpunkt getan 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 Code für die Kesselplatte hinzuzufügen, würde ich ihn hinzufügen und festschreiben, bevor ich mit dem anderen Code beginne nochmal).

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