Kuinka korjata "Git Push Rejected: Non-Fast-Forward" menettämättä muutoksia

Ei -pikasiirto hylkää Gitin toimiakseen historian suojaamiseksi, ei paikallisen työsi poistamiseksi. Yleensä se tarkoittaa, että etähaara siirtyi eteenpäin paikallisen haaran viimeisen synkronoinnin jälkeen, joten etähaaran päivittäminen nykyisellä haaralla hylkäisi siellä jo olevat commitit. GitHubin nykyinen dokumentaatio kuvaa saman tilanteen: hae ensin ylävirran muutokset, integroi ne paikallisesti ja julkaise ne sitten uudelleen.

Turvallisin yleinen työnkulku on seuraava: suojaa kaikki sitoutumaton työ, nouda etähaara muokkaamatta nykyistä haaraa, tarkista, miten historiat erosivat, valitse joko yhdistäminen tai uudelleenperustaminen, ratkaise tarvittaessa ristiriidat ja push uudelleen. Älä aloita merkinnällä git push --forcetai git reset --hardvain virheen poistamiseksi.

Tässä oppaassa käytettyjä virallisia viitteitä ovat GitHub-dokumentaatio: Dealing with non-fast-forward errors , Git: git-push documentation , Git: git-fetch documentation ja Git: git-rebase documentation .

Mitä "ei-pikakelaus" oikeastaan ​​tarkoittaa?

Oletetaan, että paikallisessa mainhaarassa on commit L, kun taas etähaarassa origin/mainon eri commit R. Jos kumpikaan commit ei ole toisen esi-isä, historiat ovat eriytyneet. Normaali push-komento ei voi yksinkertaisesti siirtää etähaaran osoitinta kohtaan Lilman, että se Rkatoaa kyseisen haaran näkyvästä historiasta.

Nopeasti eteenpäin tehty päivitys on erilainen: uusi haaran kärki on vanhan jälkeläinen, joten haaran siirtäminen eteenpäin säilyttää kaiken siitä jo saavutettavan. Virallinen git pushkäyttöohje määrittelee tämän syntyperäsäännön ja varoittaa, että se --forcepoistaa normaalin suojauksen käytöstä ja voi aiheuttaa etäcommittien katoamisen.

Ennen kuin teet mitään: onko paikallinen työsi tallennettu turvallisesti?

Suorita:

git status

Jos työpuu on puhdas, nykyiset muutoksesi näkyvät jo commit-tiedostoina ja voit luoda ylimääräisen turvaviittauksen ennen etätyöaseman integrointia:

git branch backup-before-sync

Tuo haara osoittaa nykyiseen commit-tiedostoon, joten integraatiota edeltävälle tilalle on helppo antaa nimi.

Jos olet muokannut tai poistanut seurannan tiedostoja, joita ei ole vahvistettu, valitse jokin seuraavista menetelmistä ennen tiedostojen noutoa tai uudelleenpohjustusta:

• Tee niille commit, jos työ on loogisesti valmis commit-tiedostoksi.
• Säilytä ne, jos työ on keskeneräinen git stash push -u -m "before non-fast-forward fix":.

Tämä vaihtoehto sisältää seuraamattomat tiedostot. Git-stashin-u virallinen dokumentaatio selittää, että stash tallentaa työhakemiston ja indeksin tilan ja palauttaa puhtaan työpuun. Ohitettuja tiedostoja ei sisällytetä ; -valitsin sisällyttäisi myös ohitetut tiedostot, mutta se on harvoin tarpeen tämän ongelman ratkaisemiseksi.-u-a

Tärkeää: jos git statusnäyttää tiedostoja, joita et voi menettää, älä suorita komentoa git reset --hard. Tämä komento voi hylätä vahvistamattomat työpuun muutokset.

Vaihe 1: Pitäisikö sinun käyttää git pullheti?

Voit, mutta nouto ensin -menetelmää on helpompi perustella . GitHub-dokumentit git fetchlataavat etätyön ja päivittävät etäseurantahaarat yhdistämättä näitä muutoksia nykyiseen haaraasi. Tämä tekee siitä hyödyllisen diagnostiikkavaiheen, koska voit tarkastella tilannetta ennen paikallisen historian muuttamista.

git fetch origin
git status -sb
git log --oneline --graph --decorate --left-right HEAD...origin/main

Noudon jälkeen etäseurantahaara origin/mainedustaa juuri hakemaasi etätilaa. Log-komennon avulla näet commitit, joihin voi päästä vain paikalliselta ja vain etäpuolelta.

Jos paikallisessa haarassasi ei ole yksilöllisiä committeja ja se on yksinkertaisesti jäljessä, voit usein kelata sitä eteenpäin:

git merge --ff-only origin/main

Sitten ei ole mitään soviteltavaa; haarasi yksinkertaisesti siirtyy eteenpäin.

Vaihe 2: Yhdistä vai muuta pohjaa – kumman sinun pitäisi valita?

Molemmat voivat säilyttää muutoksesi. Ero on tuloksena olevan historian muodossa.

Yhdistä reitti

git fetch origin
git merge origin/main

Jos ristiriitoja ei ole, Git suorittaa integroinnin loppuun. Jos haarat todella erosivat toisistaan, tuloksena voi olla yhdistämisvahvistus.

Reitin uudelleenpohjustaminen

git fetch origin
git rebase origin/main

Rebase ottaa nykyiselle haarallesi ainutlaatuiset commitit ja lisää ne uudelleen origin/main. Gitin rebase-dokumentaatiossa sitä kuvataan useiden committien siirtämisenä eri lähtöpisteeseen. Koska nämä commitit saavat uudet commit-tunnukset, rebase sopii parhaiten paikalliseen työhön, jota ei ole vielä jaettu julkisena historiana.

Jos haluat mieluummin oikotien, git pull --rebase origin mainsuorita nouto ja sen jälkeen uudelleenpohjustuksen, kun taas git pull --no-rebase origin mainvalitsee eksplisiittisesti yhdistämistoiminnon. Palautustilanteessa erilliset fetchja merge/ rebase-komennot ovat usein selkeämpiä, koska voit tarkastella etätilaa ensin.

Vaihe 3: Mitä sinun pitäisi tehdä, jos Git ilmoittaa ristiriidasta?

Ristiriita ei tarkoita, että muutoksesi ovat poissa. Se tarkoittaa, että Git ei voi automaattisesti päättää, miten muutokset yhdistetään samaan sisältöön.

Tarkista ensin valtio:

git status

Avaa jokainen ristiriitainen tiedosto, päätä lopullinen sisältö, poista ristiriitamerkit ja luo sitten ratkaistu tiedosto:

git add path/to/file

Jos valitsit yhdistämisen, viimeistele yhdistäminen kaikkien konfliktien valmistelun jälkeen:

git commit

Jos valitsit uudelleenasennuksen, jatka committien toistamista:

git rebase --continue

Jos uudelleenpohjustaminen menee huonosti ja haluat palauttaa haaran uudelleenpohjustusta edeltävään tilaan, käytä:

git rebase --abort

Nykyinen Gitin uudelleenpohjauskäsikirja dokumentoi erityisesti --continueja --aborttätä tarkoitusta varten. Älä käytä git rebase --skippelkästään ristiriidan poistamiseen, ellet todella aio jättää commitin uudelleentoistoa pois.

Vaihe 4: Milloin on turvallista ponnistella uudelleen?

Ennen työntämistä tarkista työpuu ja sen lähihistoria:

git status
git log --oneline --graph --decorate -n 12

Sitten paina normaalisti:

git push origin main

Jos yhdistit etähaaran tai uudelleenpohjasit vain commitit, joita ei ole koskaan aiemmin push-tiedostona lähetetty, normaali push-tiedosto on yleensä oikea operaatio, koska uusi etäkärki on paikallisen kärjen esi-isä.

Milloin kannattaa käyttää --force-with-lease?

Käytä sitä vain silloin, kun olet tarkoituksella uudelleenkirjoittanut historiaa, joka on jo olemassa etäpalvelimella — esimerkiksi olet uudistanut aiemmin julkaisemasi ominaisuushaaran ja nyt sinun on korvattava kyseisen haaran vanha commit-sekvenssi.

git push --force-with-lease origin feature-branch

Virallinen git pushdokumentaatio selittää, miksi tämä on turvallisempaa kuin pelkkä käytäntö --force: vuokrasopimus tarkistaa, että etäviitteellä on edelleen odottamasi arvo. Jos toinen henkilö on lähettänyt uutta työtä uudelleenkirjoituksesi perustana olleen tilan jälkeen, pakotettu päivitys hylätään sen sijaan, että heidän commit-tiedostonsa korvattaisiin sokeasti.

Tuo suojaus ei ole syy käyttää pakotettua puskemista rutiininomaisesti. Vältä jaettujen haarojen pakotettua puskemista, mainellei tiimisi nimenomaisesti salli historian uudelleenkirjoittamista. Palvelinpuolen haarasuojaus voi myös hylätä pakotetut puskemiset paikallisesta komennostasi riippumatta.

Älä korvaa tätä:

git push --force origin main

Plain --forcepoistaa käytöstä normaalin ei-pikakelauksen turvatarkistuksen ja voi korvata etäcommitit. Gitin oma dokumentaatio varoittaa, että se voi aiheuttaa etärepositorion committien menettämisen.

Mitä jos olet jo suorittanut väärän komennon?

Gitillä on usein vielä riittävästi paikallista historiaa aiemman haarautumispaikan palauttamiseksi. Suorita:

git reflog

Relogit tallentavat paikallisten viittausten viimeisimmät päivitykset, mukaan lukien HEAD. Jos löydät commitin, joka edusti haaraasi ennen virheellistä nollausta tai uudelleenpohjausta, luo pelastushaara sen sijaan, että siirryt välittömästi mainuudelleen:

git branch rescue-work <commit-id>

Tarkasta ja palauta nyt rescue-worktarvitsemasi commitit. Virallisessa git-reflog-dokumentaatiossa reflogit kuvataan tietueiksi siitä, mihin haarautumisvinkit ja muut viittaukset osoittivat aiemmin.

Miksi git pulljoskus luotiin yhdistämiscommit?

git pullhakee ensin ja integroi sitten valitun ylävirran haaran. Asetuksista ja tietovaraston kokoonpanosta riippuen integrointi voi olla yhdistäminen tai uudelleenperustaminen. Jos haluat ennustettavan toiminnan korjatessasi ei-pikasiirtoon perustuvaa hylkäystä, ilmaise aikomuksesi nimenomaisesti:

# Preserve branch history with a merge
git pull --no-rebase origin main

# Replay private local commits on top
git pull --rebase origin main

Parhaan näkyvyyden saavuttamiseksi käytä git fetch originensin ja suorita git merge origin/maintai git rebase origin/mainerikseen.

Entä jos etäcommit ei ole toivottu?

Älä oleta, että "ei-toivottu" tarkoittaa, että se on turvallista poistaa. Tarkista se ensin:

git fetch origin
git log --oneline --decorate HEAD..origin/main
git show origin/main

Jos commit kuuluu toiselle kehittäjälle, botille, riippuvuuksien päivittäjälle tai web-käyttöliittymässä tehdylle muutokselle, integroi tai palauta se normaalin historian kautta. Jos tiimisi on tarkoituksella suostunut korvaamaan etähistorian, vartioitu pakotettu siirto voi olla sopiva vaihtoehto – mutta se on arkiston historiaan liittyvä päätös, ei vakiokorjaus ei-pikasiirtovirheelle.

Turvallisen päätöksen tarkistuslista

• Vahvistamattomat tiedostot? Vahvista tai tallenna ne ennen integrointia.
• Tarvitsetko turvapisteen? Luo varmuuskopiohaara nykyisen commitin yhteydessä.
• Kaukosäädin vaihdettu? Juokse git fetch originennen kuin päätät, mitä tehdä.
• Jaettu historia? Käytä yhdistämistä, jos haluat välttää committien uudelleenkirjoittamisen.
• Yksityiset paikalliset commitit? Rebase voi pitää historian lineaarisena.
• Ristiriita? Ratkaise tiedosto, valmistele se ja viimeistele sitten yhdistäminen tai jatka uudelleenpohjustusta.
• Normaali integrointi valmis? Käytä normaalia git push.
• Jo julkaistu historia tarkoituksella uudelleenperustattuna? Harkitse --force-with-lease, ei yksinkertaista --force.

Lopputulos

Ei-pikakelausviesti on turvaeste, joka kertoo, että etähaara sisältää historiaa, jota ehdottamasi push-tehtävä ei säilytä. Ratkaisu ei ole tämän esteen ylittäminen. Suojaa paikallinen työsi, nouda etähaara, tarkista eroavaisuudet, integroi se yhdistämisellä tai uudelleenpohjustamisella, ratkaise konfliktit tarkoituksella ja push-tehtävä uudelleen.

Jos muistat yhden säännön, tee siitä tämä: nouda ja ymmärrä ennen pakottamista . Tämä säilyttää sekä muutoksesi että etätyöasemalla jo olevan työn – ja muuttaa pelottavan push-hylkäyksen rutiininomaiseksi Gitin synkronointiongelmaksi.