GitHub Selbsthilfegruppe

[manu]

Jetzt habe ich doch lokal einen Branch gemacht, den auf GitHub gepushed, online einen Pull Request gemacht, den online in den Master gemerged und online den branch gelöscht.
Wie kriege ich jetzt meine lokale Version aktuell gesetzt? Erwartungsgemäss müsste jetzt mein Master aktuell und der Branch verschwunden sein. Ist aber nicht so. Der Master ist nicht aktualisiert, die Version DETACHED_HEAD scheint die aktuelle zu sein.
Kann jemand etwas Licht in dieses Verfahren bringen? GitHub sollte doch easy sein, oder?
Gruss
manu

[Holger]

Also ich hab' da auch noch meine Probleme.
Vielleicht kann Christoph noch einmal (irgendwo hatten wir das schon) den grundsätzlichen Workflow mit dem Umgang des XH-Repos beschreiben?

[frase]

Na, da sagt ihr was!

Ich bin auch schon am Verzweifeln.
Ich habe z.B. minimale Modifikationen für den XHShop. Und da werden ständig neue anfallen.
Soll ich nun jedesmal Christoph bemühen? Der arme Kerl

Ich habe aber überhaupt keinen Schimmer, wie ich vorgehen soll.

[cmb]

Jetzt habe ich doch lokal einen Branch gemacht, den auf GitHub gepushed, online einen Pull Request gemacht, den online in den Master gemerged und online den branch gelöscht.
Wie kriege ich jetzt meine lokale Version aktuell gesetzt?

Im wesentlichen müsstest Du einfach nur den master auschecken, und dann von original pullen. Wenn gar nichts geht, und sonst keine Änderungen im geklonten Repo sind, dann kannst du dieses auch einfach löschen und erneut klonen.

Der entscheidende Unterschied zwischen Git und SVN ist, das ersteres ein verteiles VCS ist. Was in einem Repo gemacht wird, hat keine direkten Auswirkungen auf andere Repos. Über die Remotes werden die Repos aber quasi verknüpft, so dass man sich Aktualisierungen im origin fetchen kann (`git fetch`) und dann tatsächlich branchweise pullen kann (`git pull origin master`).

Vielleicht kann Christoph noch einmal (irgendwo hatten wir das schon) den grundsätzlichen Workflow mit dem Umgang des XH-Repos beschreiben?

Es gibt viele Möglichkeiten. Ich beschreibe mal wie ich PRs mache die nur master betreffen. Vorbereiten tue ich diese in einem eigenen Fork von cmsimple-xh/cmsimple-xh (das hat den Vorteil, dass die Feature-Branches nicht direkt im XH-Repo auftauchen; bei unseren Mengen wäre das noch kein Problem, aber wenn mal mehr los wäre, dann würde es schnell unübersichtlich). Jedenfalls klone ich mir dann mein XH-Repo (`git clone https://github.com/cmb69/cmsimple-xh`), und erstelle einen neuen Branch (`git branch foo`) und checke diesen aus (`git checkout foo`). Dort mache ich dann die Änderungen, committe (`git commit`) und pushe dann in meinen Github-Fork ('git push origin`). Dann rufe ich im Browser meinen Fork auf, wo mir angeboten wird meinen neuen Branch als Pull-Request einzureichen, was ich tue.

Wenn der PR gemerge't werden soll, dann clone ich mir das XH-Repo ('git clone https://github.com/cmsimple-xh/cmsimple-xh`), und fetche dorthinein den PR (' git fetch https://github.com/cmb69/cmsimple-xh pull/123/head:pull-request/123`). Falls noch nicht erfolgt, checke ich master aus (`git checkout master`) und merge den PR (`git merge --no-ff pull-request/123`); eventuell müssen hier noch Konflikte aufgelöst werden. Wenn nun auch im master alles passt, dann wird ins XH-Repo gepusht (`git push origin master`). Anschließen lösche ich den Feature-Branch in meinem remote Repo (`git push origin -D foo`) und ggf. in meinem lokalen Fork-Repo, falls es dieses überhaupt noch gibt (`git branch -D foo`).

Wie gesagt, es gibt auf jeden Fall diverse Alternativen dazu, aber diese bin ich gewohnt, und komme recht gut damit zurecht.

[cmb]

Ich habe aber überhaupt keinen Schimmer, wie ich vorgehen soll.

Okay, ich versuche es möglichst einfach zu halten. Am besten installierst du dir TotoiseGit. Dann gehst du in eine vorhanden CMSimple_XH installation, und legst den Ordner plugins/xhshop an. Darauf dann im Explorer das Kontextmenü aufrufen, und "Git Clone …" wählen. Im Dialog unter URL https://github.com/cmsimple-xh/xhshop eintragen, und im Feld darunter das doppelte xhshop am Ende des Pfades entfernen. Dann OK klicken. Dann kommt ein neuer Dialog, und wenn dort alles fertig und okay ist, kannst du diesen schließen.

Dann hast du eine Arbeitsumgebung, im Prinzip genauso als hättest du den aktuellen master als ZIP herunter geladen, und in die CMSimple_XH Installation entpackt.

Dann kannst du die gewünschten Änderungen vornehmen (wobei TortoiseGit im Explorer geänderte Dateien und Ordner mit einem roten Icon versieht). Wenn du fertig bist, öffnest du im Explorer wieder das Kontextmenü von xhshop, und wählst dort Git Commit -> "master". Im Feld unten werden die geänderten Dateien aufgelistet; da kannst du noch mal prüfen, ob auch alles ist wie es sein soll. Dann gibst du oben im Textfeld eine Commit-Message ein, und klickst Commit. Wenn die Änderung unkontrovers ist (z.B. Beheben eines Tippfehlers, kleine Verbesserung am CSS), dann kannst du im folgenden Dialog gleich "Push …" wählen, und da die Voreinstellungen in darauf folgenden okay sein sollten, dort einfach OK drücken. Wenn alles gut geht, dann kannst du anschließend im Repo sehen, dass dein Commit der aktuelle ist.

Sind die Änderungen kontrovers, dann bietet sich ein Pull-Request an. Das ist aber etwas komplex. Zumindest für den Anfang dürfte das Vorbereiten eines Patches einfacher sein. Das geht so: nach dem Commit pusht du nicht, sondern öffnest wieder das Kontextmenü des xhshop Ordners, und wählst dort TortoiseGit → Show Log. Im Log siehst du ganz oben deinen Commit (mit einem roten master davor). Du öffnest das Kontextmenü dieses Commits und wählst "Format Patch…". Im darauf folgenden Dialog wählst Du "Number Commits" 1, und klickst okay. Dann befindet sich im xhshop Ordner eine Datei 0001-ANFANG_DER_COMMITMESSAGE.patch. Die kannst du dann bei einem Github issue posten oder mir per E-Mail schicken. Damit deine Umgebung wieder aufgeräumt wird, gehts du wieder ins Log (der Dialog ist noch geöffnet), wählst den Commit direkt unterhalb deines Commits (hat ein oranges origin/HEAD und origin/master) davor, und im Kontextmenü dieses Commits wählst du dann "Reset master to this…" Im darauf folgenden Dialog wählst to Hard reset, und klickst OK. Dann ist der vorige Stand wieder hergestellt, so als hättest du nie committet.

Um deinen lokalen Clone zu aktualisieren, muss dieser im Explorer ein grünes Icon anzeigen (wäre z.B. nach den obigen Schritten der Fall). Dann einfach im Kontextmenü des xhshop Ordners TortoiseGit → Pull wählen, und im darauf folgenden Dialog "Fast Forward only" anklicken und OK. Im darauf folgenden Dialog wird dir dann nach einer Weile angezeigt, dass dein master "already up to date" ist, oder es werden eben die Aktualsierungen angezeigt. Dialog schließen, fertig.

Klingt alles recht komplex, aber wenn man es ein paar mal gemacht hat, dann wird der Workflow verständlich.

[frase]

Rrrrrrr, ich habe doch nun schon den Github-Desktop. Und der ist mir schon recht kompliziert.
Mit Master synchronisieren kann ich schon. Ich habe dann also immer den aktuellen Master auf dem Rechner.
Sobald ich da aber etwas ändere, klappt die Synchronisierung nicht mehr ... usw.
Ich hatte schon bei Split versucht mich da reinzufitzen.
Ich werde s nochmal versuchen - mit wenig Hoffnung

[cmb]

Rrrrrrr, ich habe doch nun schon den Github-Desktop.

Okay, den kenne ich aber nicht.

Mit Master synchronisieren kann ich schon. Ich habe dann also immer den aktuellen Master auf dem Rechner.
Sobald ich da aber etwas ändere, klappt die Synchronisierung nicht mehr ... usw.

Ja, das ist so beabsichtigt. Zum einen sollen lokale Änderungen, die noch nicht committed wurden, nicht einfach überschrieben werden, und zum anderen müssen lokale Commits berücksichtigt werden. Für beide Situationen gibt es Lösungen, aber ich kann eben nicht sagen, was der Github-Desktop da anbietet.

Im Zweifel kannst du aber hemmungslos ausprobieren, wenn du dir irgendein Repo unter https://github.com/frase-git aufsetzt, und dieses lokal klonst.

[cmb]

Da das Thema sauberes Lösen von Push-Konflikten geradean anderer Stelle aufkam, möchte ich es hier noch einmal beschreiben.

Das Szenario: ihr habt einem oder mehrere Commits in einem Clone durchgeführt (im Beispiel "Update v2"), und wollt nun pushen (`git push`). Das schlägt aber mit folgender Meldung fehlt:

Updates were rejected because the remote contains work that you do
not have locally. This is usually caused by another repository pushing
to the same ref. You may want to first integrate the remote changes
(e.g., 'git pull ...') before pushing again.
See the 'Note about fast-forwards' in 'git push --help' for details

Wenn ihr nun dem Vorschlag folgt, und ein `git pull` durchführt, sieht das Log etwa so aus:

after-pull.png

Im Prinzip ist alles richtig, aber der Commit-Graph ist etwas abenteuerlich, die Commit-Message ist fraglich, und die parents (unten) sind vertauscht. Gerade letzteres ist besonders problematisch, weil Github per Default immer die Änderungen von parent1 anzeigt.

Ich bevorzuge daher eine andere Lösung des Push-Konflikts, nämlich ein `git rebase`. Dabei werden die lokalen Änderungen quasi temporär rückgängig gemacht, der aktuelle Stand gezogen, und dann die lokalen Änderungen auf diesen Stand angewandt. Das Ergebnis:

after-rebase.png

Es sieht also genauso aus wie der Fall, bei dem es nicht zu einem Push-Konflikt gekommen wäre. Der Commit "Update v2" steht ganz oben, und zeigt nur parent1 an, und es gibt keinen Merge-Commit. Nun kann wie gewohnt `git push` ausgeführt werden.

[manu]

Ich habe jetzt den Thread nochmals durchgelesen, werde aber nicht schlauer.
Wie ziehe ich mit TortoiseGit eine saubere Kopie vom GitHub Master (in eine bestehende Kopie)?
Ja ich weiss, Kopie löschen und eine neue klonen von Github, aber in TortoiseGit sollte es doch diesen Befehl auch geben.
Wer kennt ihn?

[lck]

https://tortoisegit.org/docs/tortoisegi ... -sync.html