Bash Git Branches entwirren

[CyborgBeta]

Hallo,

kurze Frage, wie würde man Folgendes entwirren, also so, dass sich keine Branch-Pfade mehr kreuzen würden? Welche Techniken gibt es?

git log --graph --pretty=oneline --abbrev-commit --all
* 007df66 04_01 b
* 07fe28e 04_01 a
| * c7fa30a 03_02 b
| * 062f704 03_02 a
| | * 44d3ce1 02_02 b
| | * 16f55ab 02_02 a
| | | * f03e2ab 04_02 b
| | | * 0babbeb 04_02 a
| |_|/
|/| |
* | | d21ba36 04 b
* | | d6fbba4 04 a
|/ /
| | * 2d3a435 03_01 b
| | * 228d189 03_01 a
| |/
|/|
* | 9afdd6f 03 b
* | 3500daf 03 a
|/
| * d8dd590 02_01 b
| * 36f5e89 02_01 a
|/
* 076de67 02 b
* 56355d7 02 a
| * 6741e82 01_01 b
| * f7e39dc 01_01 a
|/
| * e227df1 01_02 b
| * 9ac2eb6 01_02 a
|/
* 03888da 01 b
* 3cd4742 01 a
* a38b504 Init

 

[Nero1]

Was willst du da entwirren? Das sind alles einzelne Branches. Du kannst die ungenutzten halt löschen, wenn du sie mergen willst mergen und dann löschen. Wenn du alle davon brauchst liegt das Problem ganz woanders.
Verknotet is da aus meiner Sicht gar nix, nur die Git Struktur potentiell sehr bescheiden.

 

[CyborgBeta]

Wenn du alle davon brauchst liegt das Problem ganz woanders.

Wo denn?

Ergänzung (28. November 2024)

Verknotet is da aus meiner Sicht gar nix,

Dann brauchst du wohl eine Brille.

 

[netzgestaltung]

hatten wir das nicht schonmal? jetzt hast du noch mehr kreuzungen als vor einem monat, oder?

ich würde Dir raten, Dir das mal zu überlegen:
https://nvie.com/posts/a-successful-git-branching-model/

 

[CyborgBeta]

hatten wir das nicht schonmal?

Jein. Prinzipiell schon, nur irgendwie hatte keiner eine Antwort. Und liegt auch schon ein wenig zurück.

 

[pseudopseudonym]

Du musst dir Git wie einen Graph vorstellen, genauer wie einen baum. Und jeder Knoten ist eine Änderung. Wenn du jetzt von der Wurzel bis zu einem Blatt gehst, beschreibt jeder Knoten eine Änderung, um zu dem Ergebnis zu kommen, das du am Blatt findest. Das kannst du nicht einfach vertauschen.
Wenn ich mir ein Steak brate

"Pfanne auf den Herd" -> "Öl in die Pfanne" -> "Pfanne erhitzen" -> "Steak in die Pfanne"

gibt es ein riesiges Chaos, wenn ich die Schritte vertausche. Wenn ich dann noch eine Abzweigung (branch) für Vegetarier mache:

"Pfanne auf den Herd" -> "Öl in die Pfanne" -> "Pfanne erhitzen" -> "Steak in die Pfanne"
                                                                 |
                                                                 -> "Gemüse in die Pfanne"

Wird es richtig chatorisch, wenn ich das einfach durcheinanderwerfe.

Das kannst du nicht "einfach auflösen". Da musst du schon von Hand gucken, was du wie haben willst.

 

[netzgestaltung]

nur irgendwie hatte keiner eine Antwort.

also meine Antwort, das du den code nimmst, den du ändern magst und backupst. dann die branchen alle mal löscht außer der basis branch und dann den code in einer neuen branch sauber einfügst und zwischendurch mal thematisch commitest und dann in ein paar stunden durch bist und mergen kannst magst du noch immer nicht?

 

[CyborgBeta]

dann die branchen alle mal löscht außer der basis branch und dann den code in einer neuen branch sauber einfügst

Das Rückgängigmachen stört mich. Das wäre so, als würde man erst ein Haus bauen und es dann noch einmal abreißen, weil man im Keller oder Erdgeschoss etwas vergessen hatte.

 

[wirelessy]

Du kannst die Änderungen auf nen Master/Main branch mergen und nach dem mergen löschen.
Die History der Commits bleibt dir erhalten, je nach merge Typ. Da wird nichts abgerissen.

Aber dir zu helfen ist sehr schwer mangels Kontext - es gibt keinen Kontext, um dir eine für dich angenehme Git-Nutzung zu beschreiben.
Kannst du die Inhalte der Branches etwas beschreiben?

 

[netzgestaltung]

Das wäre so, als würde man erst ein Haus bauen und es dann noch einmal abreißen, weil man im Keller oder Erdgeschoss etwas vergessen hatte.

Es ist so - nur das Haus, das du schon mal gebaut hast, baut sich bei 2. Mal in kürzester Zeit. Daher ist das nicht so Vergleichbar. Eigentlich hast du nun schon fertigteile und kannst das als fertigteilhaus nach einem prototyp sehen.

Ergänzung (28. November 2024)

Wie auch immer. Wenn du dir noch den link näher ansiehst, den ich oben gepostet habe und das mal beherzigst, solltest du auch beim nächsten prototyp nicht mehr in solche schlaufen kommen.

 

[Nero1]

Wo denn?

An deiner Art Git zu benutzen oder dein Projekt zu planen. Ich kann’s nicht bewerten, kenne das Projekt ja nicht. Aber mit Sicherheit gibt’s da bessere Wege. Wenn alles nur eigenständige Sachen sind, alles mergen und fertig is dat Ding. Wenn du an 10 Features gleichzeitig arbeitest ist das auch eher kontraproduktiv. Aber wie gesagt, ohne Details keine nähere Einschätzung möglich.

Dann brauchst du wohl eine Brille

Nö, ich seh nur nen normalen Git-Graph, mit ein paar Ästen, der nur „gekreuzt“ aussieht, weil die Konsole halt keinen schönen Baum malen kann. Nimm n anderes Tool wie Sourcetree und co, die einzelne branches nebeneinander zeigen kann, und schon gibts da keine Überlagerung mehr, wenn dich das so sehr stört.
Ein gut gemeinter Rat ist aber dennoch, dass du dir Branching Strategien und Arbeiten mit Git anschauen solltest, das könnte in Zukunft einiges vereinfachen und Verwirrungen reduzieren

 

[netzgestaltung]

Ja das wollte ich auch noch ergänzen. es nochmal neu zu machen ist einfach auch eine übung, git zu verstehen.
Denn der Tree oben und die Anfrage dazu zeigt, dass noch was fehlt beim Verständnis.

Die Änderungen, die du machen willst hast du ja irgendwo abgespeichert und kannst sie von da copy/pasten.

Ein commit ist nicht bei jedem speichern/testen nötig, sondern dann, wenn ein abschnitt einmal richtig funktioniert und du keine groben fehler mehr vermutest.

Hier nochmal der Link zu der Erklärung von Branching-Modellen: https://nvie.com/posts/a-successful-git-branching-model/ - da muß man nicht alles mitnehmen aber ein einfaches konstrukt wäre so:

• main -> Tag bei Release | bleibt bestehen, lokale und einzelne commits: verboten
• develop -> branch von main - merge nach main | bleibt bestehen, lokale und einzelne commits: verboten
• feature-<featurename> ->branch von develop - merge nach develop | wird nach merge gelöscht, lokale und einzelne commits: vorgegeben

und wenn du das mal konsequent machst, sollte das schon ganz anders aussehen.

Ergänzung (28. November 2024)

Dazu gibts hier noch ein "Housekeeping" Tutorial um lokale und remote branches aufzuräumen:
https://railsware.com/blog/git-clean-up-in-local-and-remote-branches/

Ergänzung (28. November 2024)

Ich hab jetzt hier mal zum vergleich den befehl git log --graph --pretty=oneline --abbrev-commit --all bei mir eingegeben für den vergleich(ein einfacher abschnitt):

Und so wird es von Bitbucket angezeigt:

 

[CyborgBeta]

Ich hab jetzt hier mal zum vergleich den befehl git log --graph --pretty=oneline --abbrev-commit --all bei mir eingegeben für den vergleich

Ja, siehst du? Die Ausgabe von git log würde ich nicht als "schön" oder "linear" bezeichnen.

Wenn man die Vorgänger und Nachfolger bestimmt, gibt es aber Möglichkeiten, um das wieder zu entwirren.

Stelle dir das so ähnlich wie ein Wollknäuel vor, das nicht richtig auf- oder abgerollt wurde.

Die Frage, die sich mir stellt, ist, ob da ein einfaches Rebase der lokalen Branches, die noch nicht gepusht wurden, ausreicht.

 

[BeBur]

Welches Problem versucht du zu lösen, außer das es "deiner Meinung nach nicht hübsch genug" aussieht?
Wenn es dir nicht hübsch genug ist such nach einer Darstellung, bei sich keine Pfade kreuzen. Da brauchst du nicht am repo rumfummeln.

 

[CyborgBeta]

Es ist nicht linear. Das ist mindestens ein Smell, wenn nicht Anti-Pattern.

Aber schließt dieses Thema bitte, Beschimpfungen oder unqualifizierte Kommentare brauche ich nicht.

 

[BeBur]

Es ist nicht linear. Das ist mindestens ein Smell, wenn nicht Anti-Pattern.

Ne, das ist quatsch. Davon abgesehen ist das Repo linear in jedem Branch. Ob es linear bleibt hängt von der merge-strategie ab.
"Ist so und so und irgendwo stand mal das ist nicht gut" ist aber auch keine Problembeschreibung.

 

[CyborgBeta]

Du kannst gerne eine Spaghetti-History erzeugen, wenn du das toll findest, aber deshalb müssen alle anderen es ja nicht auch falsch machen.

 

[wirelessy]

Software-Entwicklung ist in aller Regel nicht linear.
Vielleicht, wenn du als Einzelperson agierst.

Wie stellst dir das denn vor, wenn 10 Leute ne Software entwickeln? Jeder wartet, bis der andere fertig ist mit seinem Feature?

Das hier stellt ein gesundes Log dar, auch wenn du das nicht wahrhaben willst.

 

[CyborgBeta]

Software-Entwicklung ist in aller Regel nicht linear.

Dann sind die Entwickler schlicht unfähig, sauber zu arbeiten.

Kann hier jetzt bitte dicht gemacht werden? Kein konstruktiver Beitrag in Sicht.

 

[wirelessy]

Ich glaub, das Problem liegt auf deiner Seite.
Du bist immer noch Kontext schuldig geblieben, und du weigerst dich auf die anderen Beiträge auch nur im entferntesten einzugehen, weil sie nicht deinem Weltbild entsprechen.
Dass diese Leute (im Gegensatz zu dir wohl) produktiv mit Git arbeiten, Software produzieren, Repos und deren Strategien erstellen, verwalten, operieren, scheint dir egal zu sein.
Du hast Recht, und alle anderen sind doof.
Jep, ich lass deinen Thread in Ruhe.