Hallo liebe Wissende, ich habe ein Projekt in einem Git. Ich benutzte das nur als eine Art unendliches Undo. Hätte jetzt aber folgende Frage: Ich will ein neues Feature programmieren, das dazu führt, dass die Applikation einige Monate nicht mehr zu gebrauchen ist, und dann muss ich ja noch testen, etc. pp. Gleichzeitig möchte ich aber gern bekannte Fehler in der normalen Applikation, ohne das Feature, beheben. Die Fragen: Das ist doch genau sowas, wofür solche Systeme ideal geeignet sind? Ich könnte in Git einen Branch master/neues feature anlegen und ab jetzt unabhängig einfach den einen oder anderen Zwei bearbeiten? Richtig? Um den neuen Zweig anzulegen mache ich also "Branch", fange an an dem Feature zu arbeiten, mache dann immer wieder commit in den "Branch" Aber wie schalte ich jetzt um auf den Haupt-Branch um dort weiterzuarbeiten? Wenn ich entscheide, dass ich das neue Feature doch nicht will, wie werde ich den Branch dann wieder los? Vielen Dank für Hinweise! Herzliche Grüße Timm
Timm R. schrieb: > Die Fragen: > > Das ist doch genau sowas, wofür solche Systeme ideal geeignet sind? Ja > Ich könnte in Git einen Branch master/neues feature anlegen und ab jetzt > unabhängig einfach den einen oder anderen Zwei bearbeiten? Richtig? Richtig > Aber wie schalte ich jetzt um auf den Haupt-Branch um dort > weiterzuarbeiten? Verwendest du einen grafischen Client oder willst das auf der Kommandozeile machen? https://www.git-scm.com/book/de/v1/Git-Branching-Einfaches-Branching-und-Merging > Wenn ich entscheide, dass ich das neue Feature doch nicht will, wie > werde ich den Branch dann wieder los? https://git-scm.com/book/de/v1/Git-Branching-Branch-Management Servus.
:
Bearbeitet durch User
> Aber wie schalte ich jetzt um auf den Haupt-Branch um dort > weiterzuarbeiten? Oder andere Möglichkeit. In deiner IDE zwei Projekte/Workbenches/Arbeitsverzeichnisse anlegen.
Timm R. schrieb: > Hallo liebe Wissende, > > ich habe ein Projekt in einem Git. Ich benutzte das nur als eine Art > unendliches Undo. > > Hätte jetzt aber folgende Frage: > > Ich will ein neues Feature programmieren, das dazu führt, dass die > Applikation einige Monate nicht mehr zu gebrauchen ist, und dann muss > ich ja noch testen, etc. pp. > > Gleichzeitig möchte ich aber gern bekannte Fehler in der normalen > Applikation, ohne das Feature, beheben. > > Die Fragen: > > Das ist doch genau sowas, wofür solche Systeme ideal geeignet sind? Ja. > > Ich könnte in Git einen Branch master/neues feature anlegen und ab jetzt > unabhängig einfach den einen oder anderen Zwei bearbeiten? Richtig? Ja. > > Um den neuen Zweig anzulegen mache ich also "Branch", fange an an dem > Feature zu arbeiten, mache dann immer wieder commit in den "Branch" Ja. > > Aber wie schalte ich jetzt um auf den Haupt-Branch um dort > weiterzuarbeiten? Abwechselnd git checkout hauptbranch git checkout featurebranch Dazu muß man aber alle Änderungen per git commit eingetragen haben. > > Wenn ich entscheide, dass ich das neue Feature doch nicht will, wie > werde ich den Branch dann wieder los? git checkout anderer-branch git branch -d branch-den-man-loswerden will Knifflig wird es nur wenn Du dann doch beide haben willst bzw. Teile mischen. Dann geht git merge oder git cherry-pick los wobei Konflikte auftreten können die viel Zeit verschlingen bis man eine Mischung hat die funktioniert... Davor steht die Frage welchen branch man dann in welchen anderen integrieren will. Was ich auch oft mache wenn so eine Bastelei losgeht: git checkout -B temp und dann auf dem (dritten) temp-Branch arbeiten. Wenn alles ok ist kann man den umbenennen. Wenn es scheitert, einfach wieder löschen/ignorieren. > > Vielen Dank für Hinweise! > > Herzliche Grüße > > Timm
:
Bearbeitet durch User
Timm R. schrieb: > Aber wie schalte ich jetzt um auf den Haupt-Branch um dort > weiterzuarbeiten? um auf den foobar branch zu wechseln git checkout foobar um auf den master branch zu wechseln git checkout master Oder im grafischen Git Client (meist in der Log-Ansicht) mit ein oder zwei Mausklicks. Beachte daß vor dem Umschalten auf einen anderen Branch alle momentan noch uncommitteten Änderungen committet werden müssen, sonst weigert es sich (aus gutem Grund weil sonst Chaos ausbräche).
Hallo, vielen Dank für eure Antworten, dann stürze ich mich mal ins Abenteuer. vlg Timm
Timm R. schrieb: > Um den neuen Zweig anzulegen mache ich also "Branch", fange an an dem > Feature zu arbeiten, mache dann immer wieder commit in den "Branch" Solange das Feature wirklich neu ist, empfiehlt sich statt des “merging” vom master, das “rebasing” des feature branch auf den master. Gerade wenn man alleine arbeitet, bleibt dadurch die Historie schlank und übersichtlich.
> Historie schlank und übersichtlich
Böser Tipp.
In zwei Jahren hast du vergessen, warum du es so gelöst hast. Und bis
auf die Historie sind alle Aufzeichnungen verloren gegangen.
"Wieso habe ich damals so einen Unfug gemacht -- Ahh. Den Workaround
brauchte ich damals, weil ich den Hauptzweig erst später aufgeräumt
hatte."
Dumm gelaufen schrieb: > In zwei Jahren hast du vergessen, warum du es so gelöst hast. Und bis > auf die Historie sind alle Aufzeichnungen verloren gegangen. Beim Rebasen gehen doch keine Aufzeichnungen verloren, es wird doch nur die Reihenfolge geändert. Der Feature-Branch-Abzweig wird dann halt am Master immer weiter nach oben und immer wieder an die Spitze des masters geschoben. Dadurch werden alle neuen master-Änderungen Teil des Feature-Branches. Aber verloren geht da nichts. Solange man alleine an diesem Feature arbeitet hat das ständige Umschreiben der Feature-History auch keine negativen Auswirkungen. Wenn Du fertig bist kannst Du am master ein fast-forward machen und dann ist der Feature-Branch nahtloser Teil des Stammes. Verloren geht nichts, man kann nur nicht mehr auf den ersten Blick sehen daß da überhaupt jemals ein separater Branch war (nur noch wenn man sich die Zeitstempel anschaut), es sieht dann so aus als ob alles direkt am master gemacht wurde.
:
Bearbeitet durch User
Die Minusklicker mögen bitte mal darlegen welche Aufzeichnungen angeblich verloren gehen.
Karl schrieb: > Oder andere Möglichkeit. > In deiner IDE zwei Projekte/Workbenches/Arbeitsverzeichnisse anlegen. Falls du damit meinst alles zu kopieren, dann würde ich davon abraten. Gerade mit dem Branch kann man sich Fehlerbehebung auf dem Hauptbranch leicht in den Seitenzweig reinziehen (rebase oder merge). Außerdem lässt es sich am Ende leichter mergen. Sonst gibt es noch gut worktree, mit dem man sich den Stand eines Branches in einen Ordner legen kann. Damit behält man aber auch sie Möglichkeit es wieder normal zu mergen.
Timm R. schrieb: > vielen Dank für eure Antworten, dann stürze ich mich mal ins Abenteuer. Du kannst das ja auch erstmal in einem Demorepository mit Textdateien ausprobieren. Wenn du da dann den Branch ausversehen löschst ist es nicht so schlimm.
Eine Suche nach "git workflow" ergibt auch viele Meinungen/Erfahrungen/Strategien.
Bernd K. schrieb: > Die Minusklicker mögen bitte mal darlegen welche Aufzeichnungen > angeblich verloren gehen. Die Leute sind hier teilweise allergisch gegen rebase, warum auch immer. Ich hatte vor ein oder zwei Jahren auch mal eine Diskussion drüber. Am Ende konnte man den halben Thread nach /dev/null schubsen.
Nico W. schrieb: > Die Leute sind hier teilweise allergisch gegen rebase rebase ist eines der zentralen Features von git. Wer "allergisch" dagegen ist, hat schlicht und einfach keine Ahnung von git.
Merging vs. Rebasing https://www.atlassian.com/git/tutorials/merging-vs-rebasing
1 | Summary |
2 | |
3 | If you would prefer a clean, linear history free of unnecessary merge |
4 | commits, you should reach for git rebase instead of git merge when |
5 | integrating changes from another branch. |
6 | |
7 | On the other hand, if you want to preserve the complete history of your |
8 | project and avoid the risk of re-writing public commits, you can stick with |
9 | git merge. Either option is perfectly valid, but at least now you have the |
10 | option of leveraging the benefits of git rebase. |
> Die Leute sind hier teilweise allergisch gegen rebase
Mag ja sein, dass man für die Linux Projekte alle dieser Features
braucht.
Aber ich will mich nicht tagelang in diese 1000 Features einarbeiten.
Ich will nur 5 einfache Menu-Einträge in der IDE.
Keep it simple and stupid schrieb: > Aber ich will mich nicht tagelang in diese 1000 Features einarbeiten. > Ich will nur 5 einfache Menu-Einträge in der IDE. Warum stellen sich manche das immer so kompliziert vor? Außerdem wird Git in vielen IDEs unterstützt (sogar von Microsoft), sodass man dort alles auch ohne Kommandozeile machen kann. Das schöne ist aber auch, dass man parallel mit mehreren Tools arbeiten kann. Da kann man sich dann für jede Aufgabe das aussuchen, was einem am besten passt. Grundlegend sollte man sich mit dem Mergen vertraut machen, weil dies immer bei Konflikten nötig ist. Im Prinzip muss man einfach nur entscheiden, welche Seite die richtige ist oder die Änderungen beider Seiten kombinieren. Das braucht man sowohl für merge als auch rebase. Rebase ist gerade für Featurebranches, auf denen man nur alleine arbeitet sehr hilfreich. Im Prinzip werden die Commits, die man dort gemacht hat der Reihe nach ab einem Abzweigpunkt nochmal angewendet. Danach sieht es so aus, also ob man die Änderungen erst von diesem Punkt gemacht hätte, was die Übersichtlichkeit erhöht. Das schöne an Rebase ist, dass man Konflikte (wenn es welche gibt) für jeden Commit einzeln lösen muss. Damit löst man dann immer nur Konflikte, die zu einem Umbauschritt passen. Bevor man dann mit dem Rebase fortfährt kann man z.B. auch mit einem Build testen, ob die Änderungen funktionieren oder noch Anpassungen notwendig sind. Und wenn man merkt, dass man Mist gebaut hat, lässt sich ein Rebase auch wieder abbrechen und von vorne starten.
Nico W. schrieb: > Die Leute sind hier teilweise allergisch gegen rebase, warum auch immer. Ja, komisch. Ob merge oder rebase, ist piep-egal. Der Aufwand ist der gleiche. Naja, Gewohnheiten und vor allem lineares Denken lässt sich eben nur schwer aufbrechen. Zurück zum Thema: Timm R. schrieb: > Ich will ein neues Feature programmieren, das dazu führt, dass die > Applikation einige Monate nicht mehr zu gebrauchen ist, und dann muss > ich ja noch testen, etc. pp. Naja, persönlich würde ich eher zum Feature-Toggle raten. Meine Erfahrung ist, je kleiner ein Team oder Projekt, desto schneller sind unbenutzte Branches tot. Sie sterben einfach weil niemand die Ressourcen aufbringt sie zu pflegen. Und gerade ein Vorhaben über Monate ist eine Garantie dafür, dass einer der beiden Branches einfach nur austrocknen wird. In der 4ma haben wir uns von den Feature-Branches verabschiedet. Funktioniert nicht gut. In der Praxis hat man doch grob zwei Arten von Änderungen: a.) Eher viele, kleine Änderungen die mit einer Handvoll Commits und/oder an einem Tag erledigt sind. b.) Wenige, eigentlich meistens nur ein aktuelles Projekt oder der nächste, wichtige Meilenstein, die aktuelle Software irgendwie umzubauen, erweitern oder so, oft irgendwie inkompatibel. Wir machen master based Development und für b. verwenden wir Feature-Toggle. Das macht natürlich nur dann Sinn, wenn man CI am laufen hat und mindestens CD-"light". Installationen sind bei uns branches. Installationen sind statisch, und ändern sich meistens nicht mehr. Daher trocknen die branches auch aus. Wird ein update notwendig, benötigt man eh meist den aktuellen Head. Der gibt dann einen neuen Branch für eine Installation. Selten benötigt eine Installation (Branch) mal einen Patch. Den zieht man sich dann als Cherry-Pick aus dem Master. Oder der Patch ist nur Intallations-spezifisch, oder nur für zwei, drei Installationen notwendig. Dann wird unterhalb dieser (ähnlichen) Installationen (Branches) ge-cherry-pickt. Aber, das sind nur unsere Erfahrungen. Jeder wie er will. Das schöne gerade an Git ist ja, dass man sich einen Workflow bauen kann, der optimal auf seine eigenen Ansprüche angepasst ist. Git macht einem eben keine Vorschriften. Aber damit kommen manche nicht klar.
Du kannst dir auch eine workstree in einen neune Verzeichnis anlegsen z.B. auf einer Linux Maschine, sollte vielleicht auch auf Windows laufen In /home/user/source ist das original dann in dem original git worktree add /home/user/source-feature machen, dann wird eine "source-feature" branch in /home/user/source-feature angelegt. Du kannt die ganzen Commits via Cherrypick hin- und herkopieren
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.