Ich fange an, ein wenig Entwicklung in meiner Firma zu machen. Ich beabsichtige, Git für die Versionskontrolle zu verwenden, und ich bin daran interessiert zu sehen, welche Richtlinien oder Standards die Leute in der Version in ihrer Gruppe verwenden, ähnlich wie Codierungsstandards oft innerhalb der Gruppe für die Gruppe geschrieben werden.
Ich gehe davon aus, dass es Dinge wie:
geben wirdOffensichtlich hängt vieles davon ab, welches VCS Sie verwenden und wie Sie es strukturiert haben.
Ähnliche Fragen;
git Branch Benennung Best Practices
< a href="https://stackoverflow.com/questions/2006265/is-there-an-standard-naming-convention-for-git-tags"> Gibt es eine Standardnamenskonvention für Git-Tags?
In der aktuellen Umgebung, in der ich arbeite, ist das Versionskontrollsystem eines der fortschrittlichsten und ausgereiftesten. So machen wir das.
Wir haben etwas, das als "Haupt" -Abzweig bezeichnet wird und die Codebasis ist, die in Produktion sein wird. Beachten Sie, dass die Code-Basis in einer einzelnen riesigen gigantischen Struktur liegt. Sagen Sie, wenn ein neues Projekt kommt, müssen wir ein Scoping dafür machen und werden eine Release-Woche buchen. Jetzt müssen wir anfangen, daran zu arbeiten. Also haben wir einen Zweig von main als Feature-Zweig abgeschnitten. Das Team oder die Gruppe von Entwicklern arbeitet weiterhin in diesem speziellen Feature-Zweig. Beachten Sie, dass es eine Vielzahl von Feature-Zweig-Schnitten gleichzeitig vom Hauptzweig geben wird.
Sobald die Entwicklung abgeschlossen ist, ist es üblich, den Code wieder mit main zu verbinden. Wir werden es nicht direkt tun, da es wegen offensichtlicher Kritikalitäts-Probleme Verwüstungen verursachen könnte. Wir haben also einen weiteren Zweig von der Hauptversion namens Pre-Release. Wir verschmelzen unseren gesamten Code mit dieser Veröffentlichungsbasis. Und bauen Sie auf die vollständige Codebasis auf. Der Build sollte bestehen. Wenn dies der Fall ist, extrahieren wir einen grünen Zeitstempel (zuletzt bestandener Build). Sobald der grüne Zeitstempel erreicht ist, wird der Code aus dem Vorabversionszweig zu main zusammengeführt und die Veröffentlichung abgeschlossen.
Sobald der Code in Produktion genommen wurde und wir sagen, dass wir einige Bugs haben, schneiden wir einen Zweig von main, der als Bug-Fix-Zweig bezeichnet wird. Tue alle Änderungen. Und fusioniere es zurück mit main; folgt immer dem Pre-Release / Green Timestamp-Prozess. Es ist unvermeidlich.
Re-Basis. Ok, also anfangs habe ich gesagt, dass wir gebucht hätten, wenn unser Feature-Zweig fertig sein muss. Während dieser Zeit wird es eine Menge Code-Updates auf main geben. Also, es ist ziemlich notwendig, dass Sie Ihren aktuellen Feature-Zweig aktualisieren, um mit Main synchronisiert zu sein. Dazu wird ein Prozess namens Rebase ausgeführt. Es ist so, als würde man den neuesten Code von main bekommen, so dass man nicht in einer Branche arbeitet, die so veraltet ist. In meiner aktuellen Organisation wird alle 2 bis 3 Wochen eine Rückerstattung ausgelöst, obwohl die Richtlinien 1 Woche empfehlen.
Weitere interessante Features: Angenommen, ich arbeite gerade an einem so genannten Feature-Zweig und möchte Code von einem der anderen Teams erhalten, die auch in ihrem eigenen Feature-Zweig arbeiten (dieses Szenario scheint zwar ungewöhnlich, passiert aber häufig). Dafür werden wir unsere Konfigurationsspezifikation ändern (ClearCase ist unser Versionskontrollsystem), um auf die Dateien zu verweisen, die von dem anderen Projekt benötigt werden. Es kann entweder LATEST verwendet werden oder ein TIMESTAMP kann angegeben werden, um die Dateien aus dem anderen Feature-Zweig zu extrahieren.
Nach einiger Zeit, nachdem das Projekt live gegangen ist, ist der Feature-Zweig, den wir schneiden, ziemlich überflüssig. Es kann aus dem System beendet werden, sagen wir nach Jahren, sollte der Raum eine Einschränkung sein.
meine 'cvs' ist TFS also nimm es für das, was es wert ist.
Wenn jemand den Build bricht, gilt die Donut-Regel (bringt Donut am nächsten Tag)
Sie haben erwähnt, dass Sie häufig, basierend auf Tag, Woche oder Meeting, sich verpflichten. Würde dieses System unvollständigen Code nicht einführen? Es kann stabiler sein, nach der Überprüfung des Codes zu committen.
Das Einrichten von Komponententests wäre eine gute Übung, um damit zu beginnen, da es so ist, als würde ein zweites QA-Team über Nacht arbeiten (wenn diese Komponententests als Teil des Build über Nacht ausgeführt werden).
Was die Verzweigung pro Feature betrifft, so habe ich das nicht verwendet, sondern etwas, über das wir gesprochen haben, als jemand den Build kaputt gemacht hat, denn wenn ein Team ein Feature kaputt gemacht hat, ist der Rest noch aufgebaut. Damit dies funktioniert, muss Ihr Setup-Programm flexibel genug sein, um es zu erstellen und bereitstellen zu können, auch wenn optionale Funktionen fehlen.
Der Aufbau einer solchen Funktion kann die Produktivität erhöhen, da die Qualitätssicherung bereits am nächsten Tag getestet werden kann, anstatt durch einen beschädigten Build blockiert zu werden, bis sie später am Nachmittag behoben wird / p>
CVS ist bekannt, aber wenn ich ein Entwicklungsteam / -projekt starten würde, könnte ich mir Jira Studio ansehen.
Sobald Sie Ihren Masterzweig haben, sollte jede Aufgabe oder Funktion, in der Sie arbeiten möchten, in einer eigenen Verzweigung entwickelt werden. Versuchen Sie, die Master-Niederlassung jederzeit stabil und produktionsbereit zu halten. Wann immer Sie eine Aufgabe haben, verzweigen Sie einen Zweig, machen Sie Ihre Arbeit dort, beheben Sie alle Fehler, und führen Sie dann den Master zurück.
Sie müssen nicht täglich einchecken (oder eine andere Zeiteinheit). Wir machen unsere Check-Ins immer auf der Basis von Feature-Completion, nicht unbedingt einem kompletten Feature-Set, sondern in kleinen logisch überschaubaren Stücken. Dies ermöglicht es uns, Bugs leichter zu finden, als einen täglichen Check-in für den gesamten Code zu haben, unabhängig davon, ob er in Beziehung steht oder nicht.
Halten Sie Ihre Commit-Nachrichten klar und auf den Punkt, dies wird Ihnen enorm helfen, wenn Sie Ihren Code erneut aufrufen.
Ein kleiner Gotcha mit Git, wenn Sie einen Zweig verzweigen, wird er von dem Zweig, auf dem Sie gerade sind, gespalten, nicht vom Master. Dies ist eine offensichtliche Sache, aber überprüfen Sie immer Ihren aktuellen Zweig, bevor Sie einen neuen Zweig abzweigen.
Verwenden Sie die .gitignore-Datei, um Dateien, die Sie nicht mehr aus der Versionskontrolle heraus verfolgen möchten, anstatt Ihre git-Statusmeldungen zu überfluten oder eine Datei zu überschreiben, die nicht in der Versionskontrolle enthalten sein sollte (DB-Konfiguration und so)
Nur einchecken (oder, abhängig von Ihrem Tool) den Arbeitscode zum "Haupt" Zweig / stream / depot / repository hochladen (wählen Sie Ihre eigene Definition von "main"). Dieser "Haupt" Zweig sollte jederzeit kompilierbar und testbar bleiben.
Tags und Links git standards version-control