Mergen auf neuen Masterportal Version¶

1. Abrufen der gewünschten Version aus Bitbucket:

git fetch https://bitbucket.org/geowerkstatt-hamburg/masterportal tag v2.5.0     # 1a. ENTWEDER feste version abrufen
git fetch https://bitbucket.org/geowerkstatt-hamburg/masterportal dev:upstream   # 1b. ODER aktuelle dev-version in branch "upstream" abrufen

2. Auf dev-Branch wechseln

git checkout dev

3. Prüfen, dass keine offenen Änderungen mehr vorhanden sind

git status

4. Neues Branch anlegen

git branch dev2.5.0

5. Auf merge-Branch wechseln

git checkout dev2.5.0

6. Merge

git merge v2.5.0  # ENTWEDER 4a. wenn 1a gewählt wurde (Versionsupgrade)
git merge upstream  # ODER 4b. wenn 1b gewählt wurde (aktuelle dev-Version)

7. Merge-Konflikte beseitigen falls nötig (Dateien bearbeiten, anschließend mit "git add" hinzufügen, nicht gewünschte dateien mit "git rm" löschen, am Ende "git commit")

Nochmal kontrollieren, dass keine Merge-Konflikte vorhanden sind (nach "<<<" suchen)

8. Push

git push

Tipps und Tricks zum Mergen¶

webpack.config.js: Da wir diese Datei selbst pflegen, wird es keine Merge-Konflikte geben. Falls es aber zu seltsamen Fehlermeldungen kommt, kann ein Blick in die "originale" Webpack-Config (im LGV-Repo unter devtools) helfen. Vermutlich wurde dort etwas geändert - z.B. ein alias hinzugefügt oder ein Pfad verändert.

package.json: beim interaktiven Mergen in VS Code beide Änderungen übernehmen, dann bei doppelten Paketen die Zeile mit der älteren Version löschen
Achtung: Pakete dürfen auch nicht doppelt in "dependencies" und "devDependencies" auftauchen!

package.lock.json: einfach löschen und einmal "npm install" laufen lassen, dann wird die datei korrekt neu angelegt (aber vorher package.json bereinigen, siehe oben)

in git status als "deleted by them" oder "deleted by us" markierte Dateien können in der Regel mit "git rm ..." gelöscht werden

in anderen Dateien, die wir nicht verändert haben, sollten die eingehenden Änderungen akzeptiert werden falls unerwartet Merge-Konflikte auftauchen

Rückgängig machen¶

Wenn garnichts hilft:

git reset --hard 1234abcd  (durch die richtige Commit-ID ersetzen)
git push --force  (nur nötig falls schon Änderungen gepusht wurden)

Dadurch wird der dev branch erst lokal und dann im gitlab auf den angegebenen Commit zurückgesetzt.
Alle späteren Änderungen sind weg!

Alles vergleichen¶

Einen Überblick über alle Änderungen kann man leicht wie folgt erhalten. Wichtig: Vorher prüfen dass alle lokalen Änderungen commited und gepusht sind! Falls das Repo beim reset/checkout versehentlich beschädigt wird, kann es dann einfach neu geklont werden.

git status  # prüfen dass es keine lokalen Änderungen gibt
git checkout dev
git checkout -b vergleich  # branch 'vergleich' anlegen als kopie von 'dev'
git reset upstream  # git index wird auf den stand von 'upstream' gesetzt, dateien bleiben wie sie in 'dev' sind
git status  # zeigt nun alle änderungen zwischen 'upstream' und 'dev'
git reset dev  # index wieder auf den dev-branch setzen
git checkout dev  # wieder zurück zum dev-branch