Merge Request auf Gitlab

[J. V. (janvi)]

Habe von Gitlab ein (fremdes) Projekt auf meine lokale Platte geclont 
und daran Änderungen gemacht. Etwas später habe ich festgestellt, daß 
die Änderung seit einiger Zeit als "Issue" ausgeschrieben ist weil das 
andere auch gestört hat. Nachdem ich einen Screendump von meiner Version 
an das Issue angehängt habe wurde ich zum Merge Request aufgefordert.

Wenn ich jetzt aktuell einen Fork des Masters mache, ist das natürlich 
schon einiges weiter wie in der Version woran ich geändert habe. Wie 
kriege ich das am besten aufgelöst ? Geht ein Merge Request auch wenn 
ich zuvor keinen Fork gemacht habe? Oder soll ich auf den eigenen Fork 
einen Merge Request probieren und diesen dann weitergeben ?

[DPA (Gast)]

Gibt viele möglichkeiten. Ich würde folgendes tun:
Checke die neuste version als neuen branch aus, cherry-picke oder rebase 
deine relevanten änderungen, behebe konflikte, checke, ob noch alles 
lauft, dann nen merge request machen.

[J. V. (janvi)]

> cherry-picke oder rebase

ok, muß ich beides erst mal im Sandkasten üben ...

[Andre R. (physicist)]

Und da es der vorherige Poster nicht explizit erwähnt hat, bracht man im 
üblichen github workflow tatsächlich einen Fork (in github! nicht nur 
eine Arbeitskopie) auf den man den branch mit Änderungen pusht. 
Anschliessend kann man im Webinterface den merge request machen.

[J. V. (janvi)]

Andre R. schrieb:
> üblichen github workflow tatsächlich einen Fork (in github!

ja das habe ich mir schon gedacht. Das Projekt ist übrigens auf Gitlab 
nicht Github aber das macht hier wohl nur den Unterschied dass daß der 
PullRequest eben MergeRequest heisst.


Habe jetzt cherry-pick und rebase mit dem Simulator auf 
https://learngitbranching.js.org/ angeschaut. Mein Problem ist, dass die 
Beispiele dort immer nur mit einem Repository arbeiten. Auch bei Merge 
obwohl ein clone dort auch dargestellt wird. Ich habe aber zwei 
verschiedene Clones (kein Fork) mit gleichem Ursprung und 
unterschiedlichem Alter die ich zusammenführen möchte. Also einfach die 
modifizierten Dateien ins andere Verzeichnis kopieren ?

[Mathias A. (mrdelphi)]

J. V. schrieb:
> Also einfach die modifizierten Dateien ins andere Verzeichnis kopieren ?

Wenn es nur wenige Änderungen sind, dürfte das tatsächlich das 
einfachste sein. Dann im neuen Clone, also dem von deinem Fork, einfach 
einen neuen Commit erstellen, pushen und den Merge Request anstoßen.

Falls Du im bisherigen Clone dagegen schon etliche einzelne Commits 
vorgenommen hast und die gerne auch in der Form veröffentlicht haben 
möchtest, wird dieses Vorgehen schnell unübersichtlich und 
fehleranfällig.

In dem Fall würde ich beim Clone des Forks den bisherigen lokalen Clone 
als weiteres Repository hinzufügen. Dann kann man daraus z.B. einzelne 
Commits per Cherry-Pick übernehmen. Das weitere ist dann wie oben, Push 
und Merge Request.

[J. V. (janvi)]

ok, es scheint alles übersichtlich so daß ich die Methode ohne 
cherry-pick oder rebase probieren kann. Ein git pull hat mir gezeigt, 
daß sich seit meinem Arbeits-clone nicht eine einzige Zeile in dem 
Verzeichnis geändert hat wo meine Änderungen sind. Also sollte ich meine 
neuen und geänderten Dateien gefahrlos einfach in das geforkte Repo 
umkopieren können, dann branch NeuFeature, checkout NeuFeature, add 
NeueDateien, stage AlleGeändertenDateien, commit, push auf ForkRepo, und 
letztendlich merge-request auf das ursprüngliche Projekt.

> würde ich beim Clone des Forks den bisherigen lokalen Clone
> als weiteres Repository hinzufügen

Nur aus Interesse - wie würde das gehen ?

[Mathias A. (mrdelphi)]

J. V. schrieb:
>> würde ich beim Clone des Forks den bisherigen lokalen Clone
>> als weiteres Repository hinzufügen
>
> Nur aus Interesse - wie würde das gehen ?

Das geht mit:  git remote add [<options>] <name> <url>

<url> kann dabei einfach der Verzeichnisname vom anderen Repository sein 
wenn beide auf dem selben Rechner liegen

<name> kann man hier beliebig wählen, darüber kann man das neu 
hinzugefügte Remote-Repository identifizieren, z.B. in der Ausgabe von 
"git remote". Bei einem Clone-Repository gibt es dort übrigens bereits 
einen Eintrag "origin", der zu dem Repository, aus dem man gecloned hat, 
zeigt.


Anschließend dann:  git fetch <name_des_neuen_remote>


Danach hat man die Branches des neu hinzugefügten Repositories genauso 
verfügbar wie die aus dem man den Clone erstellt hat, und kann also 
genauso wie üblich damit arbeiten.