Ich habe mehrere Projekte mit einer sehr großen Code-Basis. Wir haben gerade angefangen, SVN zu verwenden, also versuche ich herauszufinden, wie ich es verwenden sollte.
Das Problem ist, dass ich, wenn ich eine Aufgabe für ein Projekt beende, eine Aufgabe auf einer anderen mit einigen Überschneidungen beginne. Oft gibt es auch eine Menge von Interrupt-getriebenen Entwicklungen. Also, mein Code ist nie wirklich in einem komplett stabilen Zustand, in dem ich mich wohl fühle.
Das Ergebnis ist, dass wir nicht wirklich das VC-System benutzen, was eine SEHR schlechte Sache ist, wir alle wissen ... also, Vorschläge?
Überprüfen Sie einen persönlichen Zweig des Codes und fügen Sie Änderungen ein. Zumindest haben Sie eine Versionskontrolle für Ihre eigenen Änderungen, falls Sie ein Rollback durchführen müssen. Sobald Sie mit dem Zustand, in dem sich Ihr Zweig befindet, vertraut sind, fügen Sie diesen Zweig wieder in den Stamm ein.
Sie können auch eine Verzweigung für jede Aufgabe auschecken, anstatt eine für jede Person. Sie können auch Änderungen an Ihrem Zweig aus dem Stamm zusammenführen, wenn jemand den Stamm ändert und Sie möchten, dass Ihr Zweig die Änderungen widerspiegelt.
Dies ist eine gebräuchliche Art, SVN zu verwenden, obwohl es auch andere Workflows gibt. Ich habe an Projekten gearbeitet, bei denen ich Angst hatte, mich zu engagieren (ich würde den Build möglicherweise durchbrechen), weil wir die Verzweigung nicht effektiv genutzt haben.
Die Verzweigung ist sehr hilfreich, um Ihren Arbeitsablauf zu unterstützen, verwenden Sie ihn, bis Sie mit der Idee des Zusammenführens vertraut sind.
Bearbeiten: "Einen Zweig auschecken" bezieht sich auf das Erstellen einer Verzweigung in Ihrem Zweigordner und das anschließende Auschecken dieser Verzweigung. Die Standard-SVN-Repository-Struktur besteht aus den Ordnern Stamm, Tags und Zweigen im Stammverzeichnis.
Also, mein Code ist nie wirklich in einem komplett stabilen Zustand, in dem ich mich wohl fühle.
Warum ist das so?
Wenn Ihre Zweigstelle für Ihre Arbeit geeignet ist (z. B. mit einer guten Namenskonvention), wird jeder wissen, dass sein HEAD nicht immer stabil ist.
In dieser Art von "Arbeits" -Zweig, setzen Sie einfach ein Etikett auf den Weg, um einige "stabile Codepunkte" anzuzeigen (die dann von jedem Tester abgefragt werden können)
Jede andere Version in diesem Arbeitszweig dient nur dazu, Änderungen aufzuzeichnen, obwohl der aktuelle Status nicht stabil ist.
Dann werden Sie später alle auf einem Zweig zusammenführen, der einen stabilen Zustand darstellen soll.
In TFS können Sie "Shelf Sets" erstellen (ich bin nicht sicher, wie sie bei anderen Anbietern von Quellcodeverwaltung genannt werden würden). Wenn Sie etwas Code zurückstellen, speichern Sie ihn in Ihrem Repository, ohne ihn einzutragen.
Der Grund dafür ist, dass wenn du an Bug XXXX arbeitest und du die Hälfte des Codes reparierst, aber nicht stabil und nicht "eincheckbar" bist, sondern NewFeature YYYY zugewiesen wirst, dann SOLLTE NICHT weiter mit der gleichen Codebasis arbeiten. Sie sollten Ihren Fehler XXXX-Code "Regal", dann geben Sie Ihre lokale Codebasis auf den neuesten eingecheckten Code zurück, und implementieren Sie NewFeature YYYY.
Auf diese Weise halten Sie Ihre Check-Ins atomar. Sie müssen sich keine Gedanken über den Verlust Ihrer Arbeit machen, da sie immer noch vom Repository gehalten wird (wenn also Ihr Computer in Flammen aufgeht, müssen Sie nicht in Tränen ausbrechen), und Sie mischen Ihre Fixes nicht für XXXX mit deinem neuen Code für YYYY. Wenn Sie dann aufgefordert werden, zu XXXX zurückzukehren (vorausgesetzt, Sie haben YYYY eingecheckt), können Sie einfach Ihr "Shelf-Set" nicht mehr verwenden und direkt dorthin zurückspringen, wo Sie aufgehört haben.
Entweder akzeptieren Sie, dass der Code in SVN nicht in einem vollständig stabilen Zustand ist, und überprüfen Sie ihn trotzdem (und reservieren Sie Zeit für Stabilisierung und Refactoring alle X Tage / Wochen, damit der Code nicht zu stark abnimmt).
Oder zwingen Sie Ihr Team, strukturierter zu arbeiten, mit minimaler unterbrechungsbasierter Entwicklung, so dass Sie guten Code einchecken können.
Die erste Option ist nicht ideal (aber besser als keine Quellensteuerung), die zweite ist wahrscheinlich unmöglich - es gibt keine dritte Option.
Wenn Sie keine Zeit haben, den Code in einen stabilen Zustand zu versetzen, haben Sie trotz allem nicht die Zeit, sich verzweigen und zusammenführen zu können.
Tags und Links language-agnostic version-control