GIT-Tags im Vergleich zu SVN-Tags und HotFix-/Patch-Management

Question

Schnelle Frage, wie man mit einem Hotfix-Szenario in SVN und GIT umgeht, bitte korrigieren Sie mich, wenn ich falsch liege.

Ich komme aus einer soliden Erfahrung mit SVN, ich habe weniger Erfahrung mit GIT und ich möchte vor allem wissen, ob meine Übersetzung in GIT in Ordnung ist (nicht die beste überhaupt!), Aber nur wenn es wie erwartet funktionieren sollte.

SVN:

1. ich auf den Stamm zu entwickeln, fragt der Kunde mich auf eine Besonderheit zu arbeiten, und ich entscheiden, auf einem Zweig

2. Das Merkmal dieses Feature zu entwickeln ist in Ordnung, ich bin dabei, es mit dem TRUNK zu verschmelzen, der in der Zwischenzeit mit einigen Änderungen aktualisiert wurde, aber der Kunde fragt mich sofort nach einer Freigabe und dass sie den Test auf den BRANCH konzentriert haben, so dass sie nicht wollen um das Feature in den TRUNK zu integrieren, aber sie wollen, dass ich den BRANCH direkt freigebe .

3. OKAY, weit genug, ich TAG der BRANCH und ich lasse es zur PRODUKTION, dann werde ich die nächsten Tage verbringen das Feature in die TRUNK für die nächste Version verschmelzen, wenn meine TRUNK Änderungen live gehen wird, außerdem entscheide ich um den BRANCH zu löschen, weil ich das nicht mehr möchte, weil die Funktion entwickelt wurde und in den TRUNK integriert wird (und ich habe den TAG, um den Basiscode zu speichern)

4. OH MEIN GOTT! Es gibt einen Fehler in der neuen Funktion, ich muss es reparieren, aber ich habe nicht die BRANCH mehr, keine Sorgen "Version der Kontrolle" sind dafür gemacht, nur Branch der Tag gerade veröffentlicht, entwickeln Sie Ihre Fix und dann freigeben es wieder, dann vergiss nicht, den Fix wieder in den TRUNK zu verschmelzen.

GIT:

1. ich auf dem MAIN_DEV Zweig bin zu entwickeln, die Kunden bitten, mich auf eine Besonderheit zu arbeiten, und ich entscheiden, auf einem FEATURE_BRANCH

diese Funktion zu entwickeln

2. Die Funktion ist in Ordnung, ich bin dabei, es mit dem MAIN_DEV zusammenzuführen, das in der Zwischenzeit mit einigen Änderungen aktualisiert wurde, aber der Kunde ist in meine neue Funktion verliebt und bittet mich, sie sofort zu veröffentlichen und sie habe sein de Fokussieren der Tests auf die FEATURE_BRANCH, so dass sie nicht wollen, dass die Feature in den Zweig MAIN_DEV zusammengeführt, aber sie wollen, dass ich direkt die FEATURE_BRANCH freigeben und ich es freigeben zur Produktion, dann werde ich die nächsten Tage damit verbringen, das Feature in MAIN_DEV für die nächste Veröffentlichung zu verschmelzen, wo meine MAIN_DEV-Änderungen live gehen, außerdem entscheide ich mich, den Feature_branch zu löschen, weil ich ihn nicht mehr möchte, weil ich die Funktion entwickelt habe ..

3. OH MEIN GOTT! Es gibt einen Bug in der neuen Funktion, ich muss es reparieren, aber ich habe nicht mehr die FEATURE_BRANCH, und ich kann es nicht in den MAIN_BRANCH beheben, da es neue Updates enthält, die ich nicht veröffentlichen möchte ... keine Sorge "version of control" wird dafür gemacht, verzweigen Sie einfach das gerade veröffentlichte Tag, entwickeln Sie Ihr Update und geben Sie es dann wieder frei. Vergessen Sie dann nicht, das Update wieder in MAIN_DEV zusammenzuführen.

Fragen:

• Es ist meine die GIT Übersetzung meines SVN Flow richtig?
• Wenn ich mein Tag aus meinem feature_branch, dann lösche ich meine feature_branch, weil die Funktion entwickelt wurde, kann ich immer HotFix oder Patches auf einem neuen Zweig aus dem Tag gerade veröffentlicht, es gibt keine Notwendigkeit, gespeichert zu halten Feature-Zweig, weil ich alles in den TAG (Code, Geschichte und so weiter) bekam. Habe ich recht?

Answer 1

Meistens korrekt. Sie können jedoch nicht zu einem Tag in Git zusammenführen. In Git sind Tags unveränderlich. Sie müssen bei jeder Änderung ein neues Tag erstellen.

Ja, wenn Sie eine Verzweigung löschen, in der die letzte Festschreibung markiert ist, ist es sehr einfach, die Verzweigung erneut zu erstellen.

---

"Ich entscheide mich, diese Funktion auf feature_branch zu entwickeln."

(main_branch) $ git checkout -b feature_branch 
(feature_branch) $ ... development ... 

"Ich markiere den Feature-Zweig und veröffentliche ihn für die Produktion."

(feature_branch) $ git tag myfeature_v1.0 

"Ich verschmelzen die Funktionszweig ..."

(feature_branch) $ git checkout main_branch 
(main_branch) $ git merge feature_branch 
(main_branch) $ ... fix merge ... 

"Ich habe den Funktionszweig löschen ..."

(main_branch) $ git branch -d feature_branch 

„Oops! Ich möchte die Funktion erstellen Verzweige wieder ... "

(main_branch) $ git checkout -b feature_branch myfeature_v1.0 
(feature_branch) $ ... fix bugs ... 

Answer 2

Ihre Annahmen sind ziemlich nah an der Marke, und Dietrichs Antwort ist gut, aber lassen Sie mich ein wenig tiefer gehen.

In git sind Zweige und Tags strukturell irrelevant. Sie sind nur kleine Haftnotizen ("Refs"), die auf einige Hex-Hash-Zahlen zeigen, die tatsächliche Commits darstellen. Zweige wechseln regelmäßig zu neuen Commits (das ist ihr Zweck), während sich Tags nur ändern, wenn Sie sie erzwingen, aber niemals automatisch geändert werden. (Es gibt Tags, die mit dem Vertrauen in große Projekte verbunden sind - diese sind völlig unterschiedlich, aber für die tägliche Arbeit irrelevant).

Jedes Commit in Git enthält den gesamten Dateibaum und ist autark.

Die Commits umspannen, was wir die „gerichtete azyklische Graph“ liebevoll nennen, die eine Phantasie Art zu sagen, dass jeder begehen beliebig viele Eltern hat (1 für eine regelmäßige verpflichten, 2 für einen regulären merge, 3+ für Krake verschmilzt die niemand von uns wahrscheinlich jemals in der Praxis sieht) und Kinder.

So. Zweige und Tags sind irrelevant, außer dass der Graph unveränderlich ist. Nichts wird jemals das ändern, was Sie begangen haben, und alle Commits werden sehr leicht zusammen mit ihren Zweigen und Tags im Graphen angezeigt. Das ist der gigantische Unterschied zur Subversion, in der man sich wirklich über diese Dinge entspannen kann. Es ist sehr schwer, etwas zu verlieren, solange Sie sich an die in den vorherigen Absätzen festgelegten Konzepte halten.

TLDR: Sie Ihre Niederlassung und Tag löschen können, und Sie werden noch mit einem kurzen Blick-sehen in gitk oder git log --graph --decorate Ordnung sein, wenn es sein muss. Alle git-Befehle übernehmen die Commit-Hash-Namen anstelle von Tag/Branch-Namen, wenn Sie versehentlich eine Referenz löschen, die Sie noch benötigen.