mikrocontroller.net

Forum: PC-Programmierung Git: Branchen für experimentelles Feature?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Reno S. (schaffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
> 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.

Autor: Nikolaus S. (Firma: Golden Delicious Computers) (hns)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für eure Antworten, dann stürze ich mich mal ins Abenteuer.

vlg
 Timm

Autor: Marcus H. (mharnisch) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dumm gelaufen (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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."

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Minusklicker mögen bitte mal darlegen welche Aufzeichnungen 
angeblich verloren gehen.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Suche nach "git workflow" ergibt auch viele 
Meinungen/Erfahrungen/Strategien.

Autor: Nico W. (nico_w)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: gitperte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kaj (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Merging vs. Rebasing
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
Summary

If you would prefer a clean, linear history free of unnecessary merge 
commits, you should reach for git rebase instead of git merge when 
integrating changes from another branch.

On the other hand, if you want to preserve the complete history of your 
project and avoid the risk of re-writing public commits, you can stick with
git merge. Either option is perfectly valid, but at least now you have the 
option of leveraging the benefits of git rebase.

Autor: Keep it simple and stupid (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erfahrener Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kernel entwickler (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.