Git - merge Datei in branch

[Crys]

Hallo miteinander,

ich bin kein Git Experte. Aktuell arbeite ich mit einem kleinen Team an einem Programm. Wir haben eine produktiv genutzte main branch und (z.B.) eine nur für die Entwickler zugängliche, aber auch funktionierende dev branch.
Wenn eine Datei "fertig" ist, wird diese von dev nach main kopiert/überschrieben ("cp dev main") oder git checkout origin/dev -- file und dann commited.

Nachteil:

• es ist umständlich, da nur am PC möglich und nicht auf der (Gitea) Weboberfläche.
• es wird der Datei verlaufen überschrieben bzw. nicht von dev mitgenommen.

Am besten wäre es, wenn man eine Datei direkt von einer branch auf die andere per Weboberfläche oder TortoiseGit übertragen könnte.

Wie macht man "dies" korrekt?

Vielen Dank!

 

[dominic.e]

Warum arbeitet ihr nicht mit PullRequests? Dafür sind diese da Oo

 

[Grimba]

https://git-scm.com/book/de/v2/Git-Branching-Einfaches-Branching-und-Merging

 

[Crys]

Warum arbeitet ihr nicht mit PullRequests?

Weil nur eine einzige Datei übertragen werden darf.

 

[Yuuri]

Sieh dir bitte den typischen Gitflow an. Du hast deinen eigentlichen master Branch (bei dir nun main), welcher immer den aktuellen Entwicklungsstand hat. Von diesem Entwicklungszweig machst du nen neuen Zweig und implementierst dort genau ein Feature. Sobald das fertig ist, "mergest" du diesen Zweig auf deinen Entwicklungszweig zurück.

Was du machst entspricht eher einem Cherry Pick und ist nicht wirklich empfehlenswert.

Weil nur eine einzige Datei übertragen werden darf.

Dann kommt nur genau diese eine Datei in den Feature-Branch und nicht mehr. Dann muss dein Entwickler die Commits entsprechend anpassen. Wenn du das nicht willst, müssen zwei Zweige, einmal fürs Feature, einmal für diese Datei gepflegt werden.

edit: Falls diese Datei unabhängig der Entwicklung aktualisiert werden muss, muss der Featurebranch entsprechend vom aktuellen master gerebased werden.

 

[dominic.e]

Ich habe irgendwie das Gefühl, dass euer Workflow da etwas (sorry) "beschissen" ist. Aber ihr zweigt von main ab, ändert diese Datei und erstellt einen PR. Dann wird auch nur diese eine Datei geändert.

Ansonsten, aber da kenn ich mich nicht sooooo gut mit aus, schaut euch doch Mal die Github Actions an. Da kannst du dir gewisse Automatismen schreiben, die im Prinzip genau sowas machen könnten.

 

[Crys]

... implementierst dort genau ein Feature.

In der Theorie klar. In der Praxis sind uns 42 Ideen gekommen, welche wir vielleicht implementieren wollen. Die meisten Ideen sind sehr eng miteinander verknüpft. Deshalb machen 42 branches keinen Sinn. Wir müssen den organisatorischen Aufwand auf ein Minimum beschränken.
Die Ideen sind im dev branch gesammelt, aber sollen erst mal noch nicht veröffentlicht werden.
Bei einem Pull Requests werden aber alle Dateien von dev nach main übertragen. Dann müsste man mühsam unzählige Dateien wieder löschen und zurücksetzten, obwohl nur eine einzige Datei hätte dazu kommen müssen.

 

[dominic.e]

Eines unserer Repos an der Arbeit:

Die Frage ist, ob es nicht wirklich Sinn ergibt, ob ihr euren Workflow etwas anpasst, damit ihr eben sauber mit Branches und Pull Requests arbeiten könnt. Das macht es am Ende eigentlich nur einfacher.

Allein schon wegen der Reviews der Pull Requests.

Ihr verwendet git irgendwie nicht ganz so, wie es eigentlich angedacht ist. Ohne das böse zu meinen.

 

[S.Kara]

In der Praxis sind uns 42 Ideen gekommen, welche wir vielleicht implementieren wollen.

Konzentriert euch auf das Wesentliche.

Gedanken machen, Plan aufstellen, an den Plan halten. Nicht einfach etwas dazudichten was vielleicht irgendwann u.U. mal gebraucht werden könnte.

Ansonsten ja, mehrere Branches aufmachen. Sonst kann das nacher niemand mehr nachverfolgen.

Falls ihr noch in der Konzenptionsphase seid: da muss man nicht gleich alles in Code gießen.

 

[Yuuri]

Die Ideen sind im dev branch gesammelt, aber sollen erst mal noch nicht veröffentlicht werden.

Warum sammelst du sowas im Zweig? Sowas erledigt man in nem Issue Tracker. Git ist zur Quellcodeverwaltung gemacht, nicht zum Abbilden einer Ideensammlung durch Zweige. Branches entsprechen Implementierungen, genauer einer Ansammlung von konkreten Änderungen (Commits) am Code. In Commits kannst du dann bspw. via #1234 Feature xyz auf Issues referenzieren.

Siehe GitHub Issues (5000+ Issues, 675 Branches btw), Gitlab Issues, gitea Issues, ...

git ist keine Projektverwaltung. Wenn du sowas suchst, bist du bei Github, Gitlab, Gitea, BitBucket, ... mit ihren Issue Trackern und Kanban Boards besser aufgehoben.

 

[Crys]

Konzentriert euch auf das Wesentliche.

Bei uns geht es um ein Programm, dass es schon mal gab, aber zu viele Bugs hatte (und nicht mehr läuft). Deshalb gibt es schon viel Inhalt. Ist damals über ca. 10 Jahre entstanden.
Der Neuentwurf wird von 3 Leute (inkl. mir) betreut. 100% Freizeit. Jedes zweite WE wird ein wenig weiter entwickelt, aber nur bei schlechtem Wetter 😉
Und nie mehr als 2h am Stück. Bei einer gigantischem Neumanagement würde das Projekt wohl einfach sterben ...

Warum sammelst du sowas im Zweig? Sowas erledigt man in nem Issue Tracker

Weil man in der branch ein Code-Schnipsel schnell mal laufen lassen kann, testen und modifizieren. Im Tracker nicht ...

 

[Enurian]

In dev sollte das liegen, was ihr bei einem Release auch im main haben wollt.
Alles, was WIP ist, liegt in jeweils von dev abgeleiteten Branches.
Wenn ihr ein Release macht, könnt ihr einen beliebigen Stand aus dev nehmen, davon branchen und in main mergen. Alle merges mit PR realisieren.
Dadurch habt ihr:

• Einen dev-Branch, der den aktuellen Entwicklungsstand wiedergibt, mit fertigen Features.
• Einen main-Branch, der den aktuell veröffentlichten Stand wiedergibt und es euch erlaubt, unkompliziert Hotfixes einzuspielen (die kommen direkt in main und danach merge in dev).
• Neue Features sind separiert, bis sie spruchreif sind.

Wenn euch das zu kompliziert ist, macht halt nur einen main und keinen dev, aber entscheidend ist so oder so, dass neue Features in separaten Branches gebaut werden.

 

[Crys]

Neue Features sind separiert, bis sie spruchreif sind.

Wo separiert?

Eine Idee von uns war es mal, dass wir zwei Repos machen:

• ein Repo das läuft (main) und ausgereifte Features hat (dev, subdev, ...)
• und ein Repo mit allen alten Zeug, Ideen usw.

Hier müsste man dann aber auch zwischen den beiden Repos "händisch" kopieren. Und man hat als nachteil auch noch zwei Issue Tracker.

 

[Grimba]

Wie macht man "dies" korrekt?

Das war deine Eingangsfrage. Du hast dafür ja nun eine Menge Anregungen bekommen. Für allesamt hast du ein Gegenargument bis sogar dahin, dass eine dafür ggf. nötige Umstellung der Arbeitsweise das Projekt sterben lassen würde. Daher vermute ich hier ganz stark, dass du dir hier damit deinen eigenen Deadlock baust. Und sei er nur im Kopf.

 

[Crys]

Daher vermute ich hier ganz stark, dass du dir hier damit deinen eigenen Deadlock baust.

Sehe ich nicht so. Ich bin dankbar für eure Vorschläge. Annehmen muss ich diese aber nicht. Das Vorhaben ist trotzdem in keiner Sackgasse, wenn die aktuelle Arbeitsweise immer noch die sinnvollste ist.

 

[dominic.e]

Sollte mein Teil zuvor unter gegangen sein ->

Wenn ihr an eurem Workflow festhalten wollt oder müsst, ist ja auch erstmal egal jetzt, dann schau dir einmal die Github Actions an. Da kannst du Abläufe/Tasks definieren welche wann wie ausgeführt werden sollen.

Da kannst du dann sowas definieren wie:

• Reagiere auf push
• Pulle branch xy
• Kopiere Datei an Stelle xy
• Branch Wechseln
• Datei an ansprechende Stelle kopieren und ersetzen
• Committen und pushen

Oder ihr arbeitet mit Cherry Picking, könnte auch noch klappen. Ihr comittet nur die eine Datei und holt euch dann per cherry picking den commit und committet das ganze.

 

[Grimba]

Das Vorhaben ist trotzdem in keiner Sackgasse, wenn die aktuelle Arbeitsweise immer noch die sinnvollste ist.

Dann gibt es für dich aber keine korrekte Lösung. Es gibt quick&dirty und sauber. Leider nicht quick&sauber. Natürlich ist bei Git nicht ein weg fest vorgegeben, aber die Hinweise hier zeigen dir ja auf, dass dein Workflow und die Idee bei Git hier wohl eher nicht harmonieren. Auch wenn du das nicht so siehst. Dann ist git ggf. nicht das richtige Tool für euren Workflow.

 

[Crys]

schau dir einmal die Github Actions an.

Danke. Das werde ich mir sicher ansehen. Klingt nach einer Möglichkeit.

Auch wenn du das nicht so siehst.

Doch, das sehe ich genauso. Nur habe ich keine bessere Lösung

 

[Yuuri]

Weil man in der branch ein Code-Schnipsel schnell mal laufen lassen kann, testen und modifizieren. Im Tracker nicht ...

Dafür entwickelt man dann Module mit Dependency Injection (such mal nach loose coupling) und integriert die dann in die eigentliche Anwendung.

Weiterhin, wenn du "Schnipsel testen" willst, baut man sich ein kleines (quick & dirty) Proof of Concept, gießt das dann in ein (sauberes) Modul, integriert das (ordentlich) in die Anwendung und liefert das schlussendlich aus.

Ansonsten baut euer Zeug einfach ein und setzt Feature Flags um, dass diese separat (de-)aktiviert werden können. Es ist dann halt nirgendwo anpass- oder wiederverwendbar. Das macht aber ggf. noch mehr Arbeit (allein das Management der Flags welche gesetzt werden können und welche nicht und welche ggf. inkompatibel sind, ...) als einfach ein Modul umzusetzen und das via Interfaces zu kapseln.

Das hat aber alles nichts mit git zu tun, sondern mit eurer unstrukturierten Arbeitsweise.

Ihr könnt auch Plugins entwickeln und die dynamisch laufen lassen. Aber dafür brauchts halt ne saubere Plugin Architektur, mit welcher ein Plug'n'Play-Ansatz möglich wäre.

Ist damals über ca. 10 Jahre entstanden.

Und warum macht ihr nun den selben Fehler? Ich seh nicht wirklich wo der Neuentwurf etwas besser machen sollte, wenn er maximal genauso "wächst".