Git rebase verliert verbindung zum feature-Branch

Normalerweise würde man von dem 2. Commit einen eigenen Branch abzweigen, die Formatierung ändern und dann zurückmergen.

Die Frage ist nur: wohin? Scheinbar willst du es ja nicht im Featurebranch haben und ob es auf dem Master was zu suchen hat, ist auch nicht klar. Außerdem macht das Merge wahrscheinlich mehr Arbeit (und ist eine beliebte Fehlerquelle), als wenn du die Änderungen direkt auf dem jeweiligen Branch machst.

In einem Ein-Mann-Projekt braucht man eigentlich auch keine Branches. Evtl. nur, wenn man verschiedene Versionen seines Programmes auslieferen will (z.B. verschiedene Mikrocontroller). Stattdessen benutze ich für sowas das Tagging. Das kennt kaum einer, ich sehe alle nur mit Branches rumeiern und Riesenprobleme verursachen.

Gruß klatschnass

Chandler B. schrieb:

Hallo,

Hallo

ich habe eine frage zu Git. ich habe einen branch(test), in dem ich schon mehrere features gemergt habe. ... Das Problem was ich jetzt aber habe, ist das alle commits, welche merges behinhalten, keine Verbindung mehr zum Feature-Branch haben. Dies ist ja auch richtig, da sich die hash durch den Rebase geändert

Richtig erkannt. Du hast den hash aber nicht geändert, der alte existiert noch, nur dein master branch zeigt nicht mehr darauf. Du hast einen neuen hash erstellt. Bzw mehrere neue.

Daher die Frage, gibt es eine Möglichkeit, einen Commit zu verändern, aber alle folgenden verbindungen zu branches zu behalten?

Nein. Du musst auch alle deine Branches auf master rebasen, denn die zeigen ja noch auf den alten hash.

Ich hab aber das Gefühl, dass du nicht aus master den rebase gemacht hast, sondern von test, kann das sein?

Zeig mal bitte den tree, z.B. via gitk --all.

PS, es gibt Gründe, warum man niemals den Hauptentwicklungszweig rebasen sollte, sondern wenn nur die feature branches...

Pilot P. schrieb:

In einem Ein-Mann-Projekt braucht man eigentlich auch keine Branches. Evtl. nur, wenn man verschiedene Versionen seines Programmes auslieferen will (z.B. verschiedene Mikrocontroller).

Sehe ich nicht so. Auch in privaten Projekten kann es hochgradig sinnvoll sein, z.B. einen stabilen main branch und einen development branch zu führen. Auch feature branches machen Sinn, du willst ja möglicherweise inkrementelle Änderungen ausprobieren? Und wenn du was ändern willst, machst du das im Feature branch, solange dieser noch nicht rebased ist, sonst hast du die Probleme, die der OP hat ;)

Stattdessen benutze ich für sowas das Tagging. Das kennt kaum einer, ich sehe alle nur mit Branches rumeiern und Riesenprobleme verursachen.

Das ist doch Quark... Git tags werden doch genau dafür benutzt, überall... Siehe z.B. https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-tag oder wo auch immer. Release -> Git Tag.

Chandler B. schrieb:

Daher die Frage, gibt es eine Möglichkeit, einen Commit zu verändern, aber alle folgenden verbindungen zu branches zu behalten?

Im Prinzip könntest Du im Rahmen Deines ohnehin geplanten "git rebase -i" die vorangegangenen merges von 4a3f7ca (feature/led) add LED-Task 5c10d2e (feature/ntp) add NTP-Task a2b6c7b (feature/wifi) add wifi-Task "droppen", und nach erfolgreichem rebase erneut jene features in Deinen test-branch mergen.

Je nach der Menge der dabei zu behebenden Konflikte kann das aber in viel Arbeit ausarten. Sowas nur für die Optik eines commit-logs zu tun, würde ich mir gut überlegen.