Not logged in. · Lost password · Register

Der Ich
93,333% Dipl.-Exzentriker
Avatar
Member since Oct 2006
3642 posts
Subject: git: wie folgende Situation richtig behandeln?
Ich habe bisher immer nur im master-Branch allein gearbeitet und das war bis jetzt auch ausreichend. Da aber bald production-release ist und dann zwei Umgebungen (development und production) existieren, die sich durch das git-Repo aktualisieren würde ich gern wissen wie ich folgende Situation vernünftig in meinen Workflow integriere. Bisher (solange es nur development ist) ist mein Flow folgendermaßen:

- coden
- git commit
- git push
- cap deploy (das ist die rails/capistrano anweisung, das projekt online auf den neuesten repo-stand zu bringen)

Jetzt ist es aber so, dass natürlich neue features nach und nach implementiert werden aber auch Bugs auftreten können die schnell gefixed werden müssen. Wie verwalte ich folgende Situation:

- production ist auf stand x
- im dev-mode implementiere ich nun ein langwieriges feature, was halb fertig sein kann
- im production fällt mir ein bug auf
- ich möchte nun nicht das halbfertige feature in den production modus miteinspielen sondern nur den bug fix
- wenn das feature fertig ist soll es in den production mode mit aufgenommen werden

Ich vermute, dass das wohl irgendwie mit branches geht und würde daher gerne wissen, wie das vernünftig und richtig geht, bzw. was da gängige Praxis ist.
* 01.10.2006, + 28.11.2011, † 31.01.2013
This post was edited 2 times, last on 2012-02-01, 10:53 by Der Ich.
mute
Ausländer
Avatar
Member since Oct 2004
1245 posts
+2 Guanta, Igor++
Ich wuerds so machen:

2 Basismoeglichkeiten:

a) Du hast einen Branch, der dein Produktivbranch sein soll. Der Head dieses Branches sollte also immer deine aktuelle Produktivversion sein. Dann hast du einen Entwicklungsbranch, der abzweigt vom Produktivbranch, und von dem spaeter auch die Features abzweigen sollen. Ist ein Feature fertig, wird er in den Entwicklungsbranch zurueckgemerged. Willst du den Produktivbranch dann auf einen neuen Entwicklungsstand anheben, kann das fast-forwarded werden auf einen Stand im Entwicklungsbranch.

b) Besser finde ich eine Alternative wo dein Entwicklungsbranch der Produktivbranch ist, und die aktuelle Produktivversion durch Tags markiert ist, wie z.b. "Version 1.1".
Jedes neue Feature ist ein eigener branch, der irgendwann vom produktivbranch abgezweigt ist. Dort werden nun die Features entwickelt. Ist das Feature fertig kann der feature-branch einfach in den produktivbranch gemerged werden. Moechtest du eine neue Version veroeffentlichen, erstellst du ein neues Tag "Version 2.1" das einen Commit im Produktivbranch markiert.
Wird jetzt im Feature-Branch ein bug im hauptprogramm gefunden und gefixt, sollte dieser bugfix als eigener commit im feature-branch eingecheckt werden. Du kannst diesen Commit dann leicht im Produktivbranch cherry-picken und hast den Bugfix dann auch im Hauptbranch. Willst du spaeter ein Feature weiterentwickeln, und sollte sich aber der Programmcode auf dem es basiert geaendert haben, kannst du den feature-branch auf einem commit im produktivbranch rebasen (z.b. Version 2.1 oder einfach den head des branches).
I didn't fail. I've just found 1000 ways that don't work.
Der Ich
93,333% Dipl.-Exzentriker
Avatar
Member since Oct 2006
3642 posts
Danke für die Antwort. Möglichkeit a) hab ich verstanden und klingt einleuchtend, b) muss ich mir nochmal durchlesen und verstehen.
* 01.10.2006, + 28.11.2011, † 31.01.2013
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
+1 Guanta
Hier findest du einige Informationen zu dem zweiten Modell: http://nvie.com/posts/a-successful-git-branching-model/
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
Noch als Zusatz zu mutes a): Wenn du einen Fehler hast, kannst du auch für den Fix einen neuen Branch vom Produktionsbranch abzweigen lassen (falls es ein längerer Fix ist - sonst direkt im Produktionsbranch), sobald er fertig ist in den Produktionsbranch mergen und dann im Entwicklungsbranch den Produktionsbranch mergen, dann hast du den Fix auch im Entwicklungsbranch (falls nötig).
Der Ich
93,333% Dipl.-Exzentriker
Avatar
Member since Oct 2006
3642 posts
Genau das war die Lösung die ich mir auch überlegt hatte. @prowl, der link sit gut, den schau ich mir heut abend genauer an. Danke nochmal an alle, damit wäre mein Problem erstmal gelöst.
* 01.10.2006, + 28.11.2011, † 31.01.2013
mute
Ausländer
Avatar
Member since Oct 2004
1245 posts
In reply to post #5
+1 blarz
Quote by rudis:
sobald er fertig ist in den Produktionsbranch mergen und dann im Entwicklungsbranch den Produktionsbranch mergen, dann hast du den Fix auch im Entwicklungsbranch (falls nötig).

Anstatt zu mergen, empfiehlt sich ein rebase des Entwicklungsbranches auf dem produktionsbranch , sonst sieht die history grauenhaft aus.
I didn't fail. I've just found 1000 ways that don't work.
rudis
SPler
(Administrator)
Member since Apr 2010
649 posts
Es sei denn natürlich er will den Entwicklungsbranch öffentlich machen, dann ist rebase keine gute Idee. Sonst ist es aber wirklich ne gute Sache, vor allem wenn man sonst sehr viel mergen müsste.
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
Geht das auch so? (Bin mir nicht sicher)


Ich habe 2 Branches: Prod und Dev
Während des programmierens im Dev entdecke ich einen Bug im Prod.
Ich committe meine aktuellen Änderungen im Dev.
Dann fixe ich den Bug im Dev und committe wieder (und merke mir die $ID. Damit habe ich im letzten Commit nur den Bug gefixed.
Ich erstelle mir jetzt einen Patch des letzten Commits mittels
git format-patch $ID
und erhalte ein $patchfile
Nun wechsle ich in den Prod branch und applye den Patch mittels
git am -s $patchfile

In Code :)

Also, während des Arbeitens im Dev finde ich einen Bug im Prod
// Erstmal alles committen
git commit -m "Saving changes for bugfix-123 in Prod"

// Bug fixen und in Dev committen
vim ...
git commit -m "Fixing bug-123"

// ID des letzten Commits geben, eben die ID des Bugfixes.
git rev-parse HEAD

// Patch des Bugfixes erstellen
git format-patch $ID --stdout > fix.patch

// Patch nach Prod schieben und Patch einpflegen
mv fix.patch ../Prod/fix.patch
cd ../Prod/
git am -s fix.patch
This post was edited 3 times, last on 2012-02-03, 04:39 by pr0wl.
John Late
johnLate
Member since Oct 2009
688 posts
Quote by pr0wl:
mv fix.patch ../Prod/fix.patch
cd ../Prod/

Ich sehe hier nur ein 2. Verzeichnis, keinen 2. Branch...
Allen ist das Denken erlaubt, vielen bleibt es erspart.
neverpanic
Member since Sep 2008
1458 posts
In reply to post #9
Quote by pr0wl:
Also, während des Arbeitens im Dev finde ich einen Bug im Prod
// Erstmal alles committen
git commit -m "Saving changes for bugfix-123 in Prod"
Anstatt hier zu commiten könntest du die Änderungen auch mit git stash auf den Stack schieben. Commits mache ich nur für sinnvolle Einheiten (es sei denn ich möchte einen Teilstatus übers Netzwerk verschieben, aber dann gibts immernoch git commit --amend).

Quote by pr0wl:
// Bug fixen und in Dev committen
vim ...
git commit -m "Fixing bug-123"

// ID des letzten Commits geben, eben die ID des Bugfixes.
git rev-parse HEAD

// Patch des Bugfixes erstellen
git format-patch $ID --stdout > fix.patch

// Patch nach Prod schieben und Patch einpflegen
mv fix.patch ../Prod/fix.patch
cd ../Prod/
git am -s fix.patch
Statt dem Umweg über den Patch könntest du mir der Commit-ID auch einfach git cherry-pick <commitish> im Prod-branch aufrufen.

Die Änderungen auf dem Stack bekommst du mit git stash pop zurück.
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
Quote by neverpanic:
Quote by pr0wl:
Also, während des Arbeitens im Dev finde ich einen Bug im Prod
// Erstmal alles committen
git commit -m "Saving changes for bugfix-123 in Prod"
Anstatt hier zu commiten könntest du die Änderungen auch mit git stash auf den Stack schieben. Commits mache ich nur für sinnvolle Einheiten (es sei denn ich möchte einen Teilstatus übers Netzwerk verschieben, aber dann gibts immernoch git commit --amend).
git stash kannte ich noch nicht, danke!

Quote by neverpanic:
Quote by pr0wl:
// Bug fixen und in Dev committen
vim ...
git commit -m "Fixing bug-123"

// ID des letzten Commits geben, eben die ID des Bugfixes.
git rev-parse HEAD

// Patch des Bugfixes erstellen
git format-patch $ID --stdout > fix.patch

// Patch nach Prod schieben und Patch einpflegen
mv fix.patch ../Prod/fix.patch
cd ../Prod/
git am -s fix.patch
Statt dem Umweg über den Patch könntest du mir der Commit-ID auch einfach git cherry-pick <commitish> im Prod-branch aufrufen.

Die Änderungen auf dem Stack bekommst du mit git stash pop zurück.

Cherry picken mag ich nicht so, das ist verschrien =)
neverpanic
Member since Sep 2008
1458 posts
Dann erklär mir doch jetzt mal, inwiefern ein Cherry-Pick etwas anderes ist als dein Verfahren, nur dass git nicht mehr weiß, dass du den Commit bereits in einer anderen Branch hattest? Wenn du Cherry-Pick nicht magst möchtest du den Bugfix in Prod einpflegen und deine Dev-Branch mittels rebase darauf verschieben, aber das wurde ja bereits erklärt.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Datenschutz | Kontakt
Powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2011 by Yves Goergen