Vielleicht ist das euch auch schon mal passiert. Mir jedenfalls passiert das immer mal wieder mal. Ich checke in ein Branch ein um zum Beispiel ein Code Review vorzunehmen. Nachdem ich fertig bin, schnappe ich mir ein Ticket und eröffne einen neuen Feature Branche. Der eine oder andere ahnt bestimmt schon, worauf ich hinaus will? Richtig – ich habe meinen neuen Feature Branch aus einem Feature Branch eröffnet. In der Regel macht man aber das so nicht. Sondern man eröffnet meistens einen neuen Branch aus dem Master heraus. Es gibt Ausnahmen, dass so zu machen. Auf die Ausnahmen werde ich aber in diesem Artikel nicht näher eingehen. In den meisten Fällen führt aber der neu eröffnete Branch aus einem anderen Branch, zu Verwirrung. Spätestens beim Pull-Request.
So war es auch bei mir mit der Verwirrung. Nachdem ich meine Arbeiten an dem neuen Ticket vollendet habe commitete ich diese Änderungen und machte dann über die Konsole meinen push mit:
git push -u origin feature/xy-99
// oder
git push --set-upstream origin feature/xy-99 Dann erhalte ich mein PR Link um diesen zu erstellen. Beim erstellen stelle ich dann mit schrecken fest. „Kacke! Da sind ja noch die Commits meines Kollegen drin.“ Wie gehen wir vor, bevor die Klugscheißer Kollegen auf Dein Pull-Request aufmerksam werden? Es gibt mehrere Möglichkeiten die Situation zu entspannen. Folgende Notfallbehandlung kann genutzt werden.
Folgendes Ausgangsszenario: (Ihr habt bereits ein PR für feature-99 gestellt und dort findet ihr die Commits des Kollegen)
Stack: Bitbucket
| (local) git branch | (remote) git branch |
| master | master |
| development | development |
| feature-1 | feature-1 |
| feature-2 | feature-2 |
| feature-99 | feature-99* |
Ein möglicher Lösungsansatz:
Wir löschen den PR über die UI (Bitbucket). Lokal wechseln wir auf den Master.
git checkout feature-99
git log
// *schreibe dir die ersten 4 Zahlen deines Commits auf
Git checkout master
git branch -D/-d feature-99
git checkout -b feature-99
git cherry-pick "f12d*" // *die ersten vier Zahlen deines Commits
git push -u origin feature-99 –force
// dann erstellst Du wie gewohnt den Pull-Request Git branch -d
Das löschen eines Branches machst Du mit git branch -d <branch-name>. Falls der Branch Jungfreudig ist und noch nicht gemerged oder gepusht wurde, wir bei dem Flag -d („kleines d“) ein Git Error kommen. Git möchte dich somit bewahren, Deine commiteten Daten zu verlieren. Falls Du dir sicher bist, dass Du das willst, kannst Du den Branch mit -D „großes D“ löschen. Falls schon gemerged oder gepusht genügt das kleine D.
Git cherry-pick
Mit git cherry-pick kannst Du andere Commits anhand ihres Selektors (Commit ID) in deinen Branch holen. Das Prizip ist einwenig wie das git stashing zu verstehen. Cherry Pick setzt dir den anderen Commit einfach in dein Branch rein. Du musst nicht einmal adden und commiten. Git Status ist clean. Ich finde git Cherry Pick abgefahren und sehr nützlich. In unserem Fall holen wir uns unsere Änderungen in den neuen Branch.
Das war ein Weg nach Rom. Mich würde interessieren wie ihr das so macht. Schreibt mir einfach in den Kommentaren und ich werde drauf eingehen.
