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 ?
:
Bearbeitet durch User
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.
> cherry-picke oder rebase
ok, muß ich beides erst mal im Sandkasten üben ...
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.
Beitrag #6144202 wurde von einem Moderator gelöscht.
Beitrag #6144230 wurde von einem Moderator gelöscht.
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 ?
:
Bearbeitet durch User
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.
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 ?
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.