GIT: Vorgehen, wenn push fehlschlägt



  • Wer kennt das nicht, man hat sich viel Mühe gegeben, und dann möchte man seine bereits committeten Änderungen in den Feature-Branch pushen. Es gibt aber ein Problem: Es gab zwischenzeitlich im selben Branch eine Änderung, zum Beispiel durch Kollegen oder die Pipeline ...

    In solchen Fällen mache ich Folgendes:
    git reset --soft HEAD~1
    git stash
    git pull
    git stash pop
    <... merge Konflikte lösen ...>
    git add
    git commit -m "Meine tolle Änderung..."
    git push

    Ist dieses Vorgehen so richtig, insbesondere das reset ...? Wie macht man es richtig?


  • Mod

    Wenn keine Konflikte, was hoffentlich der Normalfall ist, sonst solltet ihr eure Arbeitsweise/Architektur überdenken:

    1. Pull mit Rebase
    2. Push

    Wenn obiges fehlschlägt: Kommt drauf an, was du hinterher in der Änderungsliste stehen haben möchtest. Willst du eher "Ich habe die Änderungen der anderen zu den meinen zugefügt" oder "Ich habe meine Änderungen den anderen zugefügt". Deine Strategie oben ist letzteres, ersteres würde man mit einem Pull mit Merge statt Rebase erreichen.

    Deine Strategie ließe sich auch vereinfachen, wenn nicht mehrere Leute gleichzeitig an dem gleichen Branch im gleichen Codestück arbeiten, weil man dann einfach und sauber die beteiligten Branches mergen kann (wenn sie in verschiedenen Branches arbeiten) bzw. man (wie meine Antwort ganz oben) man noch viel einfacher rebasen kann (wenn sie nicht am gleichen Code arbeiten). Siehe meinen Hinweis, dass dieses Szenario eher der Ausnahmefall sein sollte, das nur auftritt, wenn zwei Leute gleichzeitig in den gleichen Branch mergen wollen.



  • Eine andere Möglichkeit ist auch:

    Ich kriege mit mein Kollege hat auf meinem branch was gepuhst, da wollte ich grade selber commiten und pushen. Dann:

    git stash 
    git pull
    git stash pop
    // ggf. Konflikte beheben
    git commit -m "My Commit"
    git push 
    

    Der Unterschied ist halt, dass man vor dem commiten merkt, da hat jemand was gepusht und dann diese Änderungen sich erstmal holt, bevor man selber commited.

    Edit: Ups grade gesehen, so machst du es ja ... nur halt mit dem reset. Ja, deine Strategie ist per se valide. Sollte aber wirklich eher selten vorkommen. Wenn das so der Standard ist, dass ihr ständig parallel auf dem selben Branch arbeitet, klingt das eher nach Problem im Workflow.



  • @Leon0402 sagte in GIT: Vorgehen, wenn push fehlschlägt:

    Wenn das so der Standard ist, dass ihr ständig parallel auf dem selben Branch arbeitet, klingt das eher nach Problem im Workflow.

    Das ist richtig. Also, es kommt nur selten vor, aber anfangs wusste ich gar nicht, weshalb mein Push immer rejected wurde ... bis mir dann auffiel, dass ein Kollege meine Arbeit schneller/besser gemacht hatte. Wahrscheinlich wäre der richtige Workflow gewesen, sich mal beim Vorgesetzten bzw. Teamler zu beschweren.

    Aber hierbei ging es eher konkret um den Fall, dass die CI Änderungen am Feature-Branch vornimmt (was ich zu spät bemerkt hatte) ...


Anmelden zum Antworten