Wie soll ich die Versionen meines Projekts auf GitHub steuern?

Ich versuche heutzutage so viel Zeit wie möglich auf GitHub zu verbringen (auch wenn ich die einzige Person im Team bei der Arbeit bin), um wirklich zu spüren, wie es für eine Unternehmensanwendung in der realen Welt aussehen wird.

Eine Frage, die ich habe, ist, die Version zu steuern . Nehmen wir an, wir haben ein Projekt gestartet. Dann gründeten die Teammitglieder einige Zweige und entwickelten sich dort. Wenn wir für die Produktion bereit sind, haben wir alle Filialen mit masterFilialen zusammengelegt. Am Ende gehen wir mit Version live 1.0.

Jetzt ist diese Version 1.0live und wir haben einige Probleme mit dieser Version dieser Software. Wir möchten mit der Entwicklung für die Version beginnen 1.1, um die Probleme zu beheben, die wir durch die Beschleunigung des Projekts eingeführt haben.

Die Frage ist nun:

Wie sollen wir hier die Versionierung steuern?

Sollten wir einen neuen Zweig für die Software erstellen v1.0und dort die Version 1.0der Software behalten und auf einigen Zweigen entwickeln (oder nicht), diese zusammenführen master, mit der Version live gehen 1.1?

Gibt es Konventionen für solche Situationen?

— Tugberk
quelle

Antworten:

Ich habe das folgende Branchenmodell gefunden (und begonnen, es zu übernehmen) :

Bild von nvie.com

^{(Bild aus dem Artikel)}

In diesem Artikel werden viele großartige Praktiken und strenge Regeln beschrieben. Ich kann es nur empfehlen.

Sehenswürdigkeiten:

In der Hauptniederlassung markieren Sie Ihre Versionen. Hier findet keine Entwicklung statt. Im Falle eines Fehlers, der in der Produktion implementiert wurde, beheben Sie den Fehler in einem Hotfix-Zweig, führen ihn zusammen und markieren eine neue Version.
Die Entwicklung erfolgt auf den Entwicklungs- und Feature-Zweigen. Persönlich mache ich Bugfixes für den Entwicklungszweig und Features für Feature-Zweige.
Wenn die Software ein Release erreicht, verzweige ich zum Release Branch. Im Release-Zweig mache ich den letzten Schliff. Versionsnummern erhöhen, Metadaten ändern usw. Und kleinere Bugfixes. Wenn es fertig ist, füge ich es zusammen, um es zu meistern, zu markieren und als Version zu bezeichnen.
Die zwei Hauptzweige: Meister ist der "heilige Zweig"; Sein HEAD ist immer der neueste Produktionscode, und Develop ist der nächtliche Zweig. Der HEAD spiegelt immer die neuesten (aber möglicherweise instabilen) Ergänzungen des Codes wider.

In Ihrem speziellen Fall hängen die Schritte davon ab, wie schnell diese Version ausgeführt wurde. Wenn die Funktionen ausgelassen würden, würde ich zur Entwicklerversion zurückkehren und das Ganze noch einmal machen. Wenn es sich um Fehler in der bereitgestellten Version handelt, würde ich zu einem Hotfix-Zweig verzweigen, die Fehler beheben, zurückführen und v1.1 markieren. Wenn es beides ist, würde ich zuerst die Fehler beheben und dann die Funktionen wie beschrieben hinzufügen.

— Tamás Szelei
quelle

Sehr informativ und detailliert. Und auch eine perfekte Übung. Es macht auch sehr viel Sinn. Master für das Produkt zu haben, macht es einfach zu warten. Ich bin so ungewohnt, eine Filiale zu markieren (oder zu verpflichten?). Kannst du mir ein paar Details dazu geben? Wie können wir nach obigem Vorbild vorgehen?

— Tugberk

In git ist das Ziel des Tags ein Commit. Es bedeutet, dass Sie sagen: "Hier ist dieses Commit, und ich nenne es von nun an 'v1.3'." In der Praxis bedeutet dies, dass Sie zum Hauptzweig wechseln, den (jetzt stabilen) Entwicklungszweig zusammenführen, festschreiben und taggen. Anschließend können Sie alle Tags auflisten und zu diesem Code zurückkehren, falls Sie wissen möchten, was in einer früheren Version in Produktion gegangen ist. Tags enthalten ein wenig mehr als das, was für die groß angelegte verteilte Entwicklung wie den Linux-Kernel nützlich ist. Bei Interesse schlage ich das Progit-Buch vor .

— Tamás Szelei

ProGit ist eines der Bücher, die ich definitiv von Grund auf lesen werde. Im Moment lese ich nur die Teile, die mich interessieren, um die Arbeit zu erledigen. Bisher haben wir uns auf Master Branch entwickelt und ich denke, ich sollte das beibehalten. Aber ich werde einen anderen Zweig mit dem Namen eröffnen productionund ihn mastergemäß obigem Modell als Zweig verwenden.

— Tugberk

Während ich dieses Modell ausprobiere, ist eine Sache, mit der ich zu kämpfen habe, dass es einige unterstützende Zweige gibt, wie in dem gegebenen Artikel beschrieben, Feature- und Release-Zweige. Es kann mehrere zukünftige Zweige geben. Beispielsweise ist FeedbackForm ein zukünftiger Zweig und ContactForm ein anderer. Das ist in Ordnung für dieses Modell, denke ich? Sollte es auch mehrere Release-Zweige geben? und wenn ja, wie soll ich sie nennen?

— Tugberk

Zuallererst müssen Sie sich nicht an den Buchstaben halten, sondern müssen lediglich Regeln festlegen, die Sie einhalten. Tun Sie, was für Sie und Ihren Teamstil am besten ist. Zweitens sind mehrere Feature- und Release-Zweige normal, es sei denn, Sie haben ein kurzlebiges Projekt mit einem Feature und einem Release :). Die Bezeichnung laut Artikel lautet release- * und feature- *. Ich vermute, Sie haben die zukünftige Versionsnummer anstelle des Sternchens für die Veröffentlichung und die Issue-Tracker-ID für die Funktionszweige angegeben.

— Tamás Szelei

Was ich die meiste Zeit gesehen habe, ist:

Master ist für Sie Produkt. Irgendwann wird Ihre zukünftige Version x.0 auf Master sein.
Sie erstellen ein Tag / eine Verzweigung für jede Version in der Produktion, damit Sie diese weiterhin für jeden Kunden unterstützen können, der dies benötigt.
Das Zusammenführen von Fixes aus dem einen oder anderen ist fallweise zu behandeln.

— xsace
quelle

Vielen Dank! Sie denken also, dass es sinnvoll ist, einen Zweig mit dem Namen v1.0 beizubehalten, v1.2 ist sinnvoll?

— Tugberk

@tugberk Solange die entsprechende Software in dieser Version vorhanden ist, ist es sinnvoll, die Zweige so zu belassen, dass Sie sie schnell entfernen können, wenn Sie einen bestimmten Hotfix-Zweig benötigen. Wenn die Software in dieser Version nicht mehr vorhanden ist (wird nicht mehr unterstützt, sodass keine Arbeit mehr möglich ist), kann es sinnvoll sein, den Zweig endgültig zusammenzuführen und dann zu löschen. Sie können sogar ein abschließendes leeres Commit erstellen (ich mache es oft am Anfang des Zweigs), um nur "Zweig schließen XXXX" zu sagen, andernfalls behalten Sie den Zweigverlauf nicht bei (reflog kann ein wenig helfen, aber dies ist pro Repository)

— Patrick Mevzek