IntelliJ GIT Local Zweig??

[MiMa]

Ich habe einen Branch erstellt, bearbeitet und grüft.
Jetzt möchte ich diesen Branch (gelbes Symbol) in den master implementieren und den Zweig aber erhalten lassen und mit dem grauen Abzweig Symbol unter dem master erhalten lassen.



Ich habe das schon ein paarmal gemacht, habe raber vergessen wie ich es gemacht hatte?
Mit den optionen in dem Kontekt Menü habe ich alles mal ausprobiert.
Es wird der master zwar aktualsiert aber der Zweig mit dem grauen Abzweigsymbol unter dem master wird nicht erstellt?

 

[KonradN]

Ich weiss gerade nicht genau, was Du meinst.

Also Elemente aus einem Branch in einen anderen Branch zu übernehmen, nennt man in der Regel merge. Du kannst also Änderungen eines Branches in den master Branch mergen.

Es wird der master zwar aktualsiert aber der Zweig mit dem grauen Abzweigsymbol unter dem master wird nicht erstellt?

Da weiss ich jetzt nicht, was Du genau machen willst. Willst Du evtl. ein rebase?

Evtl. einfach einmal https://git-scm.com/book/de/v2/Git-Branching-Einfaches-Branching-und-Merging lesen. Dann hast Du einen ersten Überblick. Generell kann ich bei sowas nur empfehlen, sich wirklich die freien Bücher anzusehen um da ein tieferes Verständnis zu gewinnen, damit man mit diversen Problemen (die unter dem Strich früher oder später garantiert kommen werden) umgehen zu können.

 

[MiMa]

Ach ich hatte ganz vergessen, das die Versionen mit den grauen Abzweigen Alphabetsich sortiert werden.
Ich hatte gedacht das die Chronologisch angezeigt werden.
Die Option "Checkout and Rebase onto ..." war die richtige Option um den Aktuellen Stand einer Version fest zu schreiben.
Da ich mit Git noch lerne muss ich mir mal überlegen wie ich die Festgeschriebenen Abzweige benenne?
Eventuell "v1.0.0 kurze Beschreibung" die Commits werden ja chronologisch sortiert.
Ich benutze oft einen neuen Branch vom Master, bevor ich eine neue Funktion entwickle erzeuge ich vom master einen neuen Branch. falls etwas völlig daneben geht um zu den letzten master zurück zu kehren.

Wobei die Commits ja das gleiche machen, kann ja auch zu einem Zustand zurück.
Danke für das Buch.

 

[Gelöschtes Mitglied 91877]

Hört sich an als ob du nach Tags suchst:

Git - Tagging

git-scm.com

 

[MiMa]

Früher ohne GIT hatte ich an dem Punkt wo ich heute ein Commit machen würde ein Zip Archiv gemacht.
Anfangs ohne Datum am Namensanfang des Archives und als das Chaos ausbrach und unerhand nahm, dann mit Datum am Namensanfang.
Jedenfalls hatte ich anschliessend keinen Überblick mehr und musste Aufwändig sichten, sortieren, löschen usw.
Es ist noch nicht so lange her, da habe ich mich dann mit Git beschäftigt bin aber im Umgang damit noch ziemlich unerfahren.
Hier ist mal die Erfahrung die ich bisher gesammelt habe und die aktuelle Struktur im Projekt.

Ich habe dem Umgang mit Git so verstanden:
Einen Branch vom master erstelle ich aktuell wenn etwas neues im Programm implementieren will, wie z.B. die integration einer Mime Liste in das Einstellungen-Fenster mit der TableView für die Listen, ein TextFeld als Filter, einen Button zum Löschen eines Eintrages und die Anzeige der Einträge in einem Label.
Ein Commit mache ich aktuell wenn die FXML bearbeitet wurde und zusätzlich die erste Methode entwicklet und geprüft habe, dann immer ein Commit nach jeder weiteren neu entwickelten und geprüften Methode.
Wenn alles für das Mime erforderliche fertiggestellt wurde, mache ich den letzten Commit dafür und anschliessend das

Checkout and Rebase onto "2024-04-11 Mime Erweiterung"

Somit erhalte ich immer einen Versions Punkt der einige Commits aller Arbeiten für die Mime Option zusammenfasst.
Ich habe keine Vergleiche wie andere das machen und ob der Umgang so optimal ist?
Über Erfahrungsaustausch und Kritik würde ich mich sehr freuen.

 

[KonradN]

Das ist schon ein Vorgehen, das so in Ordnung ist.

Was man in der Praxis nur oft findet:
a) mehrere Branche. Dann hat man nicht ein master oder main sondern man hat ggf. Branche für Produktion und Development.
b) Prozesse - so sind die Haupt-Branche oft geschützt, so dass diese nicht direkt aktualisiert werden können sondern statt dessen gibt es dann Pull Requests die dann einem festgelegten Prozess folgen (Einer erstellt diesen und dann muss dieser geprüft und genehmigt werden) Oder es gibt automatische Builds, d.h. es wird nicht manuell etwas gebaut sondern das erfolgt automatisch (So entstehen dann z.B. Nachts die Nightly Builds und so)

Das sind aber Dinge, die für eigene Projekte, an denen man nur alleine arbeitet, vermutlich zu viel Aufwand bedeuten. Du hast aus meiner Sicht somit bereits ein gutes Vorgehen gefunden.