Git rebase verliert verbindung zum feature-Branch

[Chandler B. (chandler)]

Hallo,

ich habe eine frage zu Git.
ich habe einen branch(test), in dem ich schon mehrere features gemergt 
habe.
Mein Log sieht dann wie folgt aus:

ed3024b (HEAD -> test, feature/clock, dev) control led clock
afd1141 initial implementation clock sources
4a3f7ca (feature/led) add LED-Task
5c10d2e (feature/ntp) add NTP-Task
a2b6c7b (feature/wifi) add wifi-Task
7fbc6a2 add initial main
dac2f9c (master) initial commit

Jetzt möchte ich gerne den zweiten commit etwas anpassen (7fbc6a2 add 
initial main) (nur Formatierung).
Dazu mache ich normalerweise ein

git rebase -i master

und editiere dann diesen commit.
nachdem ich fertig bin, mache ich ein rebase --continue und fixe alle 
konflikte die dadurch entstanden sind.

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 
hat.

44e22ca (HEAD -> test) control led clock
7b1206c initial implementation clock sources
0685d15 add LED-Task
2ac7d42 add NTP-Task
55ac558 add wifi-Task
a9ee1ab add initial main
dac2f9c (master) initial commit

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

[Pilot P. (klatschnass)]

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

[Jan K. (jan_k776)]

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.

[Lutz V. (lutz_vieweg)]

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.