Ah, erről jól lemaradtam bocsánat. Mese következik, elnézést :) Igen, ez egy elég jó példa, mert viszonylag triviális, de könnyű beszopni, leginkább azért, mert nem érted az adatmodellt, vagy legalábbis nem hasznáod/gondolkodsz abban, de nem segít az sem, hogy a parancsok nevezéktanja csak kérdéses összefüggésben áll ezzel a modellel. Én mindig azt szoktam mondani a kiscserkészeknek, hogy mikor a gittel dolgoznak, akkor nem fileokban gondolkozunk (mint itt imho te is tetted), hanem commitokban (amik changesetek), az ezek közti összefüggésekben, és értsük meg, hogy branch simán csak egy pointer egy commitra. (Meg azért is jó példa, mert világosan mutatja, hogy ugyanazt hányféle képpen lehet megközelíteni.)
Ha innen közelíted a problémádat, hamar rájössz, hogy neked nem az a bajod, hogy a git nem tudja kezelni, hogy a két file változás után tök ugyanaz, hanem valójában 2x van meg ugyanaz a változás (hiszen két commit), emiatt nem lesz reprodukálható az út az alapállapot és a remote teteje között, mert eltérnek az állomások, és neked igazából csak semmi szükséged az egyikre (mert van egy másik, azonos tartalmú changed). Jelen esetben jellemzően arra, ami a gépeden volt mászkálás előtt, mert gondolom a laptopon utána csináltál még ezt-azt. Szóval tulajdonképpen azt akarod elérni, hogy a helyi pointered a remote tetejére mutasson. És akkor innen már (attól függően, hogy mennyire ismered a parancsokat), trivi:
git fetch #lehúzza a remote brancheket, de a pullal ellentétben nem basztatja a helyi pointert
git reset --hard origin/master #egyszerűen odabaszom a lokális pointert a távoli munka tetejére. A hard azért kell, mert vannak lokális changek, amiket le akarok szarniHa nincs még meg, hogy a távoli branchek állapotát így lehet használni, akkor megközelítheted úgy, hogy az utolsó helyi változtatásra nincs szükségem (erre ugye rá is jöttél: "ha nem commitoltam volna a módosítást lokálba"). Ezt egy `git reset --hard HEAD^1` megoldja, a helyi pointer eggyel visszább megy, az utolsó commit változásai pedig mennek a levesbe, egyből mehet a `git pull`. --hard nélkül ott maradnak commitolatlanul, , de így már csak nyikorogna, hogy vannak local changek, és simán csak visszacsinálhatnád, ahogy akarod, akár kezeddel akár git resettel, amit már elárul a git status kimenete :) A HEAD^1 a parrent commit, de ha ez sincs meg, simán git log, kinézed az idt az akart állapotnak, aztán odaírod. Hiszen ez meg csak pointer aritmetika :)
---
Egyébként általában az a jó stratégia, hogy kerüljük, hogy párhuzamosan ugyanazon a branchen dolgozzunk, a branch olcsó (hiszen csak egy pointer ;), mehetnek a különböző témák külön, ha befejeztük, push, főleg, ha vándorlunk. Ha ez nem megy, pl mert többen dolgozunk rajta, akkor lefetcheled, és rebaseled az egyik állapotot a másikra. Jellemzően a remote tetejére a helyi véltozásaidat. Ez újra végig csinálja a már meglevő commitjaid a remote tetején (új commitok, új parentekkel), ettől kiegyenesedik a vonat (persze, ha konflict volt, akkor kitalálod mi legyen). Egy jó interaktív rebassel még a sorrendet is rendbe teheted. Viszont utána nincs mese, force push jön, szóval a másik oldalon lehet játszani a szopadékot :)